nicht angemeldet
Hi!
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 ein Interface ganz leer ist, also auch nicht von einem anderen etwas geerbt hat, dann kann man nicht dagegen programmieren. Außer, es bildet die gemeinsame Grundlage für andere Interfaces. Dann kann man zumindest mit instanceof darauf prüfen, muss aber zur konkreten Bedienung dann doch von den Erben wissen, was man da ansprechen kann.
PHP kennt vordefinierte Interfaces. Eins davon ist Traversable, das leer ist, aber die Grundlage für Iterator und IteratorAggregate bildet. PHP behandelt intern vermutlich die beiden letztgenannten Interfaces separat. Als Programmierer kann man jedoch auf instanceof Traversable prüfen, oder das als Code Hint angeben, um eine Iterierbarkeit eines Objekts festzustellen/festzulegen.
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.
Einen zusätzlichen Default-Konstruktor, der ein fest vorgegebenes Objekt instantiiert, brauchst du nicht unbedingt. Wenn du richtige DI mit DI-Framework machst, dann ist es eigentlich seine Aufgabe, die Auflösung von Abhängigkeiten sicherzustellen und dafür zu sorgen, dass es ein Fehler ist, wenn für eine Abhängigkeit keine Erfüllungen (weiß grad nicht, ob es dafür einen Fachbegriff gibt) konfiguriert wurden.
Lo!