nicht angemeldet
Hey dedlfix,
bin nach einem super Wochenende wieder zu Hause und kann Euch jetzt auch wieder auf Eure Beiträge antworten.
[...] Ich habe schon Designs gesehen, in denen ein leeres Interface (keine definierten Methoden) einfach nur "weil man es so macht" definiert und von einer einzigen Klasse implementiert wurde.
In so nem Fall würde sogar ich mich wundern, was das soll :-)Vielleicht ist das wirklich nicht bedacht, vielleicht auch nur ein Versuch, für zukünftige Erweiterungen gewappnet zu sein. Indem man nicht gegen eine Klasse sondern gegen ein Interface programmiert, ist man flexibler. Allerdings ist ein leeres Interface nicht weiter sinnvoll, denn was von einer implementierenden Klasse soll man denn dann durch das Interface garantiert aufrufen können (solange es nicht von einem anderen ein paar Methoden erbt und nur zusätzlich einen konkreteren Namen bereitstellt, nebst der späteren möglichen Erweiterbarkeit)?
Bis gerade dachte ich, ein (vermeintlich) leeres Interface macht überhaupt keinen Sinn. Aber wenn ich das gerade so lese, kann es ja doch Szenarien geben, in denen so etwas Sinn macht. Also wieder eine "kommt auf den Fall an"-Entscheidung? Oder verstehe ich das falsch?
Wenn der Konstruktor des Objekts also selbst was instanziiert, dann ist das KEINE Dependency Injection.
So hat dedlfix das auch erklärt. Ich bin dabei, das umzusetzen. Danke für die Erklärung!Man kann da natürlich auch einen zweiten Konstruktor ohne Übernahmeparameter für das DI-Objekt erstellen, der sich ein Default-Objekt selbst erstellt. Das ist dann der im Gegensatz zum anderen ein Nicht-DI-Konstruktor. Der ruft mit dem selbst erstellten Objekt den DI-Konstruktor auf. Man kann dann also beide Wege fahren. Unter PHP gibts ja keine Methodenüberlagerung, also macht man da den DI-Parameter optional (mit null als Default-Wert) und wenn da nichts kommt, erstellt man sich sein Default-Objekt, ansonsten DI. Das ist insofern sinnvoll, wenn man hauptsächlich oder für den Moment nur die eine Klasse geplant hat, trotzdem aber erweiterbar (YAGNI) und - viel wichtiger - testbar bleiben möchte.
Gut, ich glaube, ich hab's jetzt (nach mehreren Ausführungen endlich :-) ) verstanden: DI ist ein gutes Mittel um einer Klasse spezielle Methoden oder Eigenschaften "aufzuprägen", sollte aber durch eine "Standard-Implementation" (was passiert, wenn kein "spezielles Objekt" übergeben wurde?) ergänzt werden. Korrigiert mich bitte, wenn dem nicht so ist. Ansonsten versuche ich, das in Zukunft so zu verwenden.
Mit großem Dank und Gruß,
Dennis