nicht angemeldet
Hi!
[...] 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)?
Also vielleicht ist es sowas wie der vorauseilende Gehorsam, der auch für jede Eigenschaft Getter und Setter vorsieht, die nichts weiter als reine Zuweisung und Lesen machen und bei der man YAGNI was anderes brauchen wird.
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.
Lo!