Tach!
Ich nehme mal an, dass sich Sven dazu noch äußern wird, er kennt sich besser in Software-Architektur aus.
Um das Speichern muss ich mich nicht explizit kümmern. Will ich auch nicht. Ich bin faul, das macht der Destruktor des jeweiligen log-Objekts für mich.
Gut, aber ich als Neuer in dem Projekt weiß das nicht, dass da solch ein Mechanismus existiert und ich sehe ihn auch nicht einfach so. Ich sehe nur, dass da was geloggt wird und hab dann auf eine unersichtliche Weise Mail im Briefkasten. Erst wenn ich mir die Nebenklasse zum Logging anschaue, löst sich das Rätsel auf. Don't let me think, das muss ich schon noch zur Genüge bei den wirklichen Problemen der Geschäftslogik.
Wichtig ist mir vor Allem, dass ich hinterher mit den gefilterten Meldungen noch etwas anfangen kann. Dafür brauche ich das wachsende Array...
Also, ich würde es besser finden, das man sich dann explizit um diesen Datenberg kümmert. Notfalls müssen Referenzen zu den Log-Objekten eben noch in einem globalen Repository abgelegt werden, das man am Ende durchläuft und auswertet. Damit kommst du auch ans Ziel und der Prozess ist offensichtlicher. Es ist auch nicht so (soll jedenfalls nicht sein), dass man nun ständig selbst an das Aufräumen denken muss. Der Log-Endverwerter wird einfach irgendwo am Ende vom Front-Controller aufgerufen und tut sein Ding - nur eben explizit und nicht implizit durch Destruktoren.
dedlfix.