nicht angemeldet
Tach!
D - Dependency Inversion Principle: Dahinter verbirgt sich u.A. das, was als Dependency Injection bekannt ist. Wenn eine Klasse eine weitere Klasse für Unteraufgaben benötigt, soll es diese Klasse nicht selbst instanziieren, sondern sich von außen hereinreichen lassen.
Ich dachte, es wäre ebenfalls ein Grundsatz von OOP, dass eine Klasse oder allgemein ein Benutzer einer Klasse möglichst wenig über deren „Inneres“ wissen müssen sollte. Wie verträgt sich dies mit dem Grundsatz, in der Klasse benötigte Instanzen per DI mitzugeben, statt in der Klasse selbst zu erzeugen? Sollte ich nicht optimalerweise gar nicht wissen müssen, wie Unteraufgaben innerhalb der Klasse gelöst werden?
Eine Klasse ist ja kein Selbstzweck. Sie muss irgendwas bearbeiten und braucht dazu Daten oder andere Objekte. Wenn du kein DI-Framework mit automatischer Abhängigkeitsauflösung einsetzen möchtest, kannst du auch Konstruktoren verwenden, die ohne explizite Übergabe sich selbst ein Objekt einer benötigten Klasse erzeugen. Das ist für überschaubare Projekte durchaus ein brauchbarer Kompromiss. Damit lässt du dir immer noch die Möglichkeit offen, ein Mock-Objekt zum Testen oder im Einzelfall irgendwas anderes zu übergeben.
Bei einem Controller, der für die Bearbeitung von Personendatensätzen ausgelegt ist, ist es außer zu Testzwecken eher ausgeschlossen, dass er mit anderen Datenquellen als dem Personenrepository arbeiten muss. Es ist deshalb wohl keine Unart, dass er sich per Default ein Personenrepository besorgt und für Testläufe auch mit einen Mock-Repository versorgt werden kann. Aber je generischer die Aufgabe einer Klasse ist, desto nützlicher ist es sicherlich, dass sie flexibel zu beeinflussen ist.
Solche Regeln haben keinen Gesetzescharakter. Sie haben sich gebildet, weil sie sich in der Praxis bei einer Vielzahl von Projekten als günstig erwiesen haben. Das heißt nicht, dass das nun die einzig mögliche OOP-Programmierweise ist. Wenn deine Ansprüche für ein konkretes Projekt weniger hoch sind, darfst du durchaus davon abweichen.
Und kommt es nicht auch zu einer Kollision damit,
- Ich bin auch kritisch eingestellt gegenüber der Strategie, schon sehr viel im Konstruktor auszuführen. Da Objekte üblicherweise erst einmal erstellt werden, und eventuell nie benutzt werden, zumindest nicht in allen Aspekten, sollte man die Dinge, die nicht zwingend zur Lebensfähigkeit des Objekts gehören, möglichst erst dann ausführen, wenn es tatsächlich notwendig ist.
denn wenn die Instanz einer für Unteraufgaben benötigten Klasse von außen herein gereicht wird, wird sie ja ebenfalls in jedem Fall erzeugt – auch wenn sie vielleicht nie benötigt wird.
Dependency Injection muss nicht nur über den Konstruktor erfolgen, man kann die notwendigen Dinge auch bei Methodenaufrufen übergeben. Dann muss man sie erst erzeugen, wenn die Methode tatsächlich verwendet wird.
dedlfix.