nicht angemeldet
Hey dedlfix,
zuerst einmal eine kleine Info zum aktuellen Stand des ursprünglichen Problems: Nach heutigem Gespräch dürfen wir _vorerst_ auch fertige Komponenten verwenden. Allerdings nur, "wenn dies auch erlaubt ist" (wann es erlaubt ist, konnte nicht beantwortet werden; also heißt es jetzt erstmal "Lizenzen wälzen") und wenn _jede_ Code-Zeile der externen Komponente kommentiert wird. Das ist für uns zwar ein kleiner Fortschritt; der Sinn hinter den Kommentaren erschließt sich mir aber nicht. Ich komme mir grade vor, als ob ich ein PHP-Tutorial schreiben sollte...
Na gut, genug geweint :-) Gerade DI interessiert mich aber auch unabhängig von der ursprünglichen Frage, nachdem Ihr mir das schmackhaft gemacht habt.
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.
Gut, dann habe ich das richtig verstanden. Hätte es aber auch gern so klar ausgedrückt...
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.
Sehr gutes, konkretes Beispiel für's Verständnis!
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.
Jetzt weiß ich zumindest, welche Aufgabe unter anderem ein DI-Framework leisten sollte. Aber das alles innerhalb so kurzer Zeit zu verstehen, ist mir zuviel des Guten :-) Ich werd' mich in der nächsten Zeit diesbezüglich mal etwas einlesen und würde mich freuen, wenn Du mir bei vielleicht aufkommenden Fragen weiterhin so toll helfen könntest.
In einem anderen Post habe ich ja schon den Blog von Fabien Potencier erwähnt. Der hat auch einen Artikel zu DI. Ohne Dir den jetzt komplett durchlesen zu müssen: Hört sich der Artikel vernünftig an, um DI besser zu verstehen?
Gruß, Dennis