Java...
-
Okay, aber das klingt für mich nach einer allgemeinen Schwäche des Codes, die weder etwas mit DI vs. non-DI noch C++ vs. Java zu tun hat. Wenn man Code gut schreibt, dann abstrahiert man Lösungen, sobald man erkennt, dass sie abstrahierbar sind. Und dann sind sie automatisch wiederverwendbar. Also kann man das genau so in Java wie in C++ implemenntieren.
-
Eisflamme schrieb:
Ich kann mit Policies nichts anfangen. Ich kenne von C++ nur policy-based-design und das hat damit nix zu tun...
doch. die misten Vorteile die bei DI angesprochen werden kann man auch analog mit PBD implementieren. Mocing geht zum Beispiel ganz toll. Ansonsten ist das Strategy Pattern auch als Policy bekannt.
Also merke ich mir: DI ist das Policy-Pattern mit XML Dateien um eine Ebene mehr Meta werden zu können. Da Policies aber seit jeher mithilfe von Factories verwaltet wurden...was ist nun an DI anders als an Policy? Kann mir das jemand aufdröseln? So mit einem UML Diagramm das genau herausstellt, wo der Unterschied liegt?
-
otze schrieb:
Eisflamme schrieb:
Ich kann mit Policies nichts anfangen. Ich kenne von C++ nur policy-based-design und das hat damit nix zu tun...
doch. die misten Vorteile die bei DI angesprochen werden kann man auch analog mit PBD implementieren. Mocing geht zum Beispiel ganz toll. Ansonsten ist das Strategy Pattern auch als Policy bekannt.
Also merke ich mir: DI ist das Policy-Pattern mit XML Dateien um eine Ebene mehr Meta werden zu können. Da Policies aber seit jeher mithilfe von Factories verwaltet wurden...was ist nun an DI anders als an Policy? Kann mir das jemand aufdröseln? So mit einem UML Diagramm das genau herausstellt, wo der Unterschied liegt?
Abhängigkeit vermeiden.
-
macht Strategy von Haus aus. Noch mehr?
-
Ne, deine Strategy kennt alle Implementierungen die es zurückgeben kann.
-
otze schrieb:
Also merke ich mir: DI ist das Policy-Pattern mit XML Dateien um eine Ebene mehr Meta werden zu können.
Das seh ich eben nicht so. Vielleicht wenn du von einem IoC Container sprichst. Aber der Begriff "DI" sagt noch gar nichts über XML Dateien oder zusätzliche Meta Ebenen. Auch Policies sind für mich eine Ausprägung der DI Idee. Das ist eben etwas was man beeinflußen, konfigurieren kann. Das ist Gegenteil davon, dass sich die Komponente die Daten selber, intern holt, ohne dass man es beeinflußen kann. Und das ist für mich viel entscheidender als die Frage, ob man das über über XML Dateien und einen IoC Container macht (was auch cool ist und was man sicher auch in C++ machen würde, wenn es möglich wäre), oder ob man das über Template Argumente zusammenfrickelt. Und wenn du dynamische Strategie-Policies verwendest (würde ich auch machen, würde man auch in Java machen), dann bist du in C++ erstmal genauso weit wie auch in Java. Keiner zwingt dich, die Abhängigkeiten automatisch reinzugeben, kannst auch manuell machen. Nur gibts bei Java noch grundsätzlich zusätzlich noch die Möglichkeit, das automatisch zu tun. Was aber wie gesagt nicht entscheidend ist.
-
Moment, PBD würde jede Klasse zum Template abwandeln. Für große Projekte geht dann doch die Compiletime in den Himmel. Finde ich nicht wirklich praktikabel anwendbar. Oder habe ich einen Denkfehler?
-
Eisflamme schrieb:
Oder habe ich einen Denkfehler?
Ja, ein bisschen schon. PBD ist das compile time Strategie Pattern. Das passt oft auch nicht. Habe ich selber z.B. ganz selten verwendet, aber es kommt auch auf den Code drauf an, den man schreibst. Nimm das richtige Strategie Pattern, das sind auch Policies, nur dynamisch. Hab ich schon sehr viel äfter verwendet, macht bei meinem Code sehr viel öfter Sinn.
-
Okay, also lässt sich das jetzt darauf zusammenfassen, dass man in C++ statt "meistens" das Strategy-Pattern verwendet, um gewisse Vorteile, die sonst DI mit sich brächte, zu erhalten: beispielsweise die Möglichkeit anzubieten für Tests Mock-Objekte reinzugeben. Also so was wie normale Parameterübergabe des zu injizierenden Objektes im ctor oder via Setter, aber eben basierend auf einem Interface, sodass es austauschbar ist.
Würdest Du in C++ irgendwas Spezielles machen, um schichtenübergreifend ganz viele Objekte gepackt an die nächste Schicht weiterzureichen? Beispielsweise irgendwelche Kontexte basteln (was - soweit ich das verstanden habe - ja einfach ne struct mit bestimmten Namen wäre?!)? Oder einfach ganz normal alle auflisten?