ich habe hier ein paar sehr kluge Programmierer, die nur den Regeln folgen und dabei gar nicht merken, wie verworren, komplex und total überkandidelt das Ganze mittlerweile ist. Aber sie reiten auf den von Dir immer wieder zitierten Regeln herum und finden es total geil, sich 3 Tage über SRP den Kopf zu zerbrechen, anstatt es einfach 'einfach' zu gestalten. Ein sehr schönes Thema für einen anderen Thread.
Genau aus diesem Grund hab ich vorhin geschrieben, dass das ganze Clean Code, Principles und Patterns Gedöns kein Selbstzweck ist. Aber jeder, der sich mit der ganzen Thematik wenigstens ein bisschen auseinander gesetzt hat und etwas davon in die Tat umgesetzt hat, hat bestätigt, dass das positiv war. Was raus kommt, wenn mans übertreibt kann man sehr schön
an dieser Fizzbuzz Implementierung sehen.
Zitat:
mir hast Du das noch nicht gesagt.
Prima, dann hab ich ja doch noch jemanden erreicht, dem ich das noch nicht gesagt habe
Ich hab mir das ja auch nicht selber ausgedacht, man kann das auch oft in Artikeln zu dem Thema lesen.
Erstmal die Prinzipien und vor allem das DIP verstehen und manuell anwenden, bevor man sich einem IoC Container zuwendet. Ansonsten wird man nämlich ganz schnell ziemlich böse davon überfahren und benutzt nen IoC Container am Ende als
Service Locator.
Zitat:
Aber dann verstehe ich deinen Einwand auch nicht: Ich habe ein Kommando als oberste Instanz. Dies führt eine Aktion und alle damit verbundenen weiteren Aktionen aus (Speichern, loggen, drucken, validieren etc.) Dem muss ich doch alle Abhängigkeiten übergeben, oder wie geht das sonst?
Wenn man das betrachtet, als ob dein Kommando das alles selbst macht. Macht es aber eventuell gar nicht. Möglich ist an dieser Stelle zum Beispiel, das
Chain- of-responsibility Pattern zu verwenden, so dass ebend nicht alles direkt innerhalb des einen Kommandos ausgeführt wird, sondern eins das nächste ausführt. Auch hier wieder beachten: wie flexibel und austauschbar möchte ich die Kommandos haben. Die Aktionen Speichern, Loggen, Drucken, Validieren operieren ja normalerweise auf einem anderen Objekt. Und je nachdem, wie man die geschrieben hat (Speichern ist ja immer eins der Paradebeispiele für "Wat kann ich eijentlich mit dieser
RTTI und Attributen so machen?") hat man mehr oder weniger wiederverwendbare Bausteine, die man in verschiedenen Reihenfolgen aneinander ketten kann.
Eins steht aber auf jeden Fall fest - und das mag für manche befremdlich sein: man muss recht viel stumpfen Code für die Erstellung und Zusammentackerei schreiben. Und das ist am Ende das, was der IoC Container einem abnehmen kann.