Auf diese Weise kennt ein Spiel zwar nicht unmittelbar sein Turnier, kann dieses aber bei Bedarf ermitteln und dort z.B. die Ermittlung der Platzierungen veranlassen (das sollte ja erfolgen, wenn ein Spiel neue Ergebnisse hat).
Für SOOO schlecht halte ich dieses Konstrukt eigentlich nicht.
Ich schon. Was hat ein Spiel mit den Platzierungen zu tun? Ich werf nochmal so einen Begriff in den Raum:
Single Responsibility Prinzip. Lösung für das Konkrete Problem:
Observer (aka Events)
Deinen letzten Satz kann ich nicht im Detail nachvollziehen. Sollte man BL-Klassen und Datenklassen getrennt definieren und erzeugen? Wo liegt der Vorteil?
Klares kommt drauf an. Aber es geschieht oft, dass die Businesslogik in diesen Klassen fehl am Platz sind und man damit zwangsläufig wieder irgendwelche Prinzipien (z.B. LoD oder SRP) verletzt. In deinem geschilderten Fall könnte es aber in der Tat Sinn ergeben, den Weg über einen Container zu gehen.
Um es nochmal zu erwähnen: Beschäftigt euch erst mit DI an sich, verinnerlicht, was man dadurch gewinnt und was man ggf aufgeben muss (in der Regel schlechte Angewohnheiten). Die Benutzung eines DI Containers ist eine Stufe weiter. Wenn man nicht manuell DI betreiben kann (TSomeComponent.Create(OtherComponent) IST dependency injection!), kann man's auch nicht mit nem Container.
Ich bin in der gleichen Situation wie Stahli, arbeite also an allein an einem über die Jahre gewachsenem Projekt. Ich habe mich in letzter Zeit ebenfalls mit den hier besprochenen Teckniken beschäftigt und sie für mich verworfen. Das ganze Kram führt zu imo zu "over engeneering". Zu Spring habe ich eine Session bei der EKON besucht und diverse Literatur durchgeackert. Es ist mir gänzlich verborgen geblieben wobei mich ein solches Framework unterstützen könnte.
Unit testing lohnt den Aufwand nicht, und Interfaces benutze ich nur wenn ich gezwungen bin mich mit
COM zu beschäftigen. In meiner Software sehe ich keinerlei Mehrwert gegenüber abstrakten Methoden. Demeters Gesetz hat was für sich, als allgemeiner Ratschlag. Aber wer sich ständig dran hält schreibt sich die Finger Wund. Für (fast) nichts. Selbst Heiligtümer wie die GOF Patterns haben sich für mich als nur eingeschränkt nützlich erwiesen. Die eine oder andere Idee dahinter ist OK und lässt sich nutzen. Das war es aber auch schon. Wiederverwendbarkeit ist gut, aber um den alten Spruch zu bemühen: Was nach allen Seiten offen ist, ist vermutlich auch nicht ganz dicht. Offensichtlich schlage ich mich nur mit trivialen Problemen herum. Ich habe mich noch nicht in der Situation befunden, ein Problem nicht mit einer einfachen und klaren dem Anwendungsfall angepassten Objekthierachie lösen zu können. Es werden viele Säue durch viele Dörfer getrieben. Ich denke zu viele.
Ich arbeite selber an einem über Jahre gewachsenen Projekt und erlebe täglich die Probleme, die mit Nichtbeachtung diverser Prinzipien einherkommen (stundenlange Suche in weniger bekanntem Source und nachverfolgen bestimmter Programmabläufe durch Bereiche hindurch, wo sie nix zu suchen haben z.B.)
Was man davon hat, wenn bestimmte Schnittstellen nicht flexibel sind, kennt jeder, der schonmal von verschiedenen Herstellern ein Mobiltelefon hatte (hey, jeder hat seinen eigenen Stecker für das Ladekabel...) Und wie gut, dass man man in der Regel nicht beim Kauf einer neuen Glühbirne den Hersteller der Lampe wissen muss, weil die ihre eigenen Fassungen haben, oder? Oder dass der Hersteller seine Lampen nur mit 40 Watt Osram Birnen getestet hat und sie mit den anderen Herstellern kaputt geht. Aber bei Software muss immer alles ineiner verbacken sein und wenn man von Modularität spricht, wird die "over engeneering" Karte ausgespielt.