DI-Container

[dr.e.]

Dynamisch ist Fluch und Segen zugleich. Bei einer generischen Factory oder einem DI-Container musst du mit statischen Type-Hints arbeiten, damit du in deiner IDE intelli-sense nutzen kannst. Mit generics ist der IDE das auch ohne klar.

[joshiausdemall]

Das beschränkt sich aber nicht ausschließlich auf Generics, sondern ist ein allgemeines "Problem", das sich, wie Du sagst, mit Doccomments hinten lässt. Generics sind Compiletime-Zucker, um Code-Duplication zu vermeiden, mehr nicht. Früher (pre-generics) musstest Du immer von Object nach T casten, was natürlich mehr als mies ist - und Typ-Fehler konnten auch nur zur Runtime herausgefunden werden. In einer dyn. typisierte Sprache braucht man Generics nicht zu vermissen, denn ihr Fehlen ist eher als Feature der dyn. Typisierung zu verstehen. Vermisst man Generics, vermisst man statische Typen - dann sollte man sich ggf. einen anderen Stack suchen.

Afraik kann man übrigens allen nennenswerten IDEs heutzutage den Listentyp ebenfalls mitgeben, die Notation lautet dann in etwa so "/*@var array{Käse} myListOfKäse: An array of Käse*/" - so oder so ähnlich.

Also ich sag' mal so: Bevor PHP Generics beherrscht, hätte ich lieber endlich Zahlen als Sprungmarken für´s Goto, damit es sich endlich wie BASIC anfühlt, und vor allem nativen Annotation-Support Aber mal sehen, was da noch so kommt, es tut sich ja momentan schon einiges...

[lstegelitz]

Zahlen als Sprungmarken für´s Goto, damit es sich endlich wie BASIC anfühlt

omg, das willst du doch nicht wirklich, oder?

goto war schon zu C-Zeiten ein Zeichen für schlechten Stil... und eigentlich nur ne Krücke für fehlende Strukturierungsmöglichkeiten.

Spaghetti-Code

[joshiausdemall]

Ich versuch' demnächst, den ironischen Teil ein wenig deutlicher herauszustellen Sorry.

[lstegelitz]

Damn... de fehlt mir doch glatt das <ironie>-Tag

[dsentker]

Um nochmal den Kern dieses Threads aufzugreifen. Ich verstehe erst jetzt so langsam den Sinn hinter DI-Containern, aber ich verstehe nicht was die Bindings in der Konfiguration sollen. Gehst du davon aus, dass ein bzw. mehrere Config-Angaben in verschiedenen DI-Container-Elementen mehrfach vorkommen? Oder warum werden sie nicht direkt den Services zugeordnet?

PS: Kann mir jemand sagen, wo ich bei den DI-Containern das "Dependency Injection" finde? Für mich ist ein sog. DI-Container nichts anderes als eine Fabrik für viele unterschiedliche Klassen.

[fab]

PS: Kann mir jemand sagen, wo ich bei den DI-Containern das "Dependency Injection" finde? Für mich ist ein sog. DI-Container nichts anderes als eine Fabrik für viele unterschiedliche Klassen.

Der Container benutzt Dependency Injection bei den "fabrizierten" Objekten (von diesen implementiert), kümmert sich also darum, dass die Abhängigkeiten verfügbar sind.

Man sagt auch IoC Container: "Inversion of Control", die Klassen müssen sich nicht mehr selber darum sorgen, wo ihre Abhängigkeiten her kommen. Der Begriff ist eigentlich treffender, da er beschreibt was der Container bewirkt und nicht wie.

[dsentker]

Der Container benutzt Dependency Injection bei den "fabrizierten" Objekten (von diesen implementiert), kümmert sich also darum, dass die Abhängigkeiten verfügbar sind.

Sorry, vielleicht stehe ich auf dem Schlauch, aber genau das sehe ich hier nicht. Ich sehe, dass ein Objekt erzeugt wird (wahlweise als Singleton), dies mit Methodenaufrufen versorgt wird (um es zu konfigurieren) und es dann zurückgegeben wird. Da passt IoC-Container tatsächlich besser zu.

Dependency Injection ist für mich

$bettMoebel = new Moebel(new HolzMoebel(new Bett(new MatratzeKaltschaum(Matratze::TYP_EXTRAWEICH)))); 

[fab]

Das ist wenn überhaupt* eine pervertierte Form von Constructor Injection, es gibt aber auch noch Setter Injection. Hier ist wiederum egal wie die Abhängigkeiten injiziert werden.

dies mit Methodenaufrufen versorgt wird (um es zu konfigurieren)

Es geht eben nicht um Konfiguration (das ist nur ein zusätzlicher Aspekt) sondern um die Bereitstellung von Abhängigkeiten. Hier mal eine simplifizierte Container-Methode:

public function bett() {
  $bett = new Bett();
  $bett->setMatratze($this->matratze()); // DEPENDENCY INJECTION
  return $bett;
} 

*) ich verstehe nicht, warum ein Möbel ein Holzmöbel benutzen sollte, welches wiederum ein Bett benutzt. Aber vielleicht ist das Beispiel auch nur zu unsinnig

[notyyy]

Dependency Injection ist für mich

$bettMoebel = new Moebel(new HolzMoebel(new Bett(new MatratzeKaltschaum(Matratze::TYP_EXTRAWEICH)))); 

das nenn ich decoration
ich preferiere da momentan diese lösung:
http://anydi.ainfach.de/decoration

praktisch habe ich damit noch keine erfahrung, derzeit experimentiere ich nur.

[fab]

[OT]Hmmm, du dekorierst deine Matratze mit Möbeln?[/OT]

[dsentker]

Es geht eben nicht um Konfiguration (das ist nur ein zusätzlicher Aspekt) sondern um die Bereitstellung von Abhängigkeiten.

Ah.. ich glaube jetzt fällt der Groschen. Das heisst, einige Konstruktoren / Methoden von Klassen / Objekten, die Teil des DI-Containers sind, benötigen wiederum andere Klassen / Objekte aus dem DI-Container?

class EinfacherContainerZurVeranschaulichung {
    
    public function getBett() {
        $bett = new Bett();
        $bett->konfiguriere($this->holeKonfigurationFuer('bett');
        $bett->setDefaultMatratze($this->getMatratze()); // DI
        return $bett;
    }

    public function getMatratze() {
       $ma = new Matratze();
       $ma->setTyp(Matratze::KALTSCHAUM);
       $ma->setInhalt($this->getFeder()); // DI
       return $ma;
   }
 
} 

(dein Beispiel kam dem ja schon sehr nah)

Das ist wenn überhaupt* eine pervertierte Form von Constructor Injection [...] ich verstehe nicht, warum ein Möbel ein Holzmöbel benutzen sollte, welches wiederum ein Bett benutzt. Aber vielleicht ist das Beispiel auch nur zu unsinnig

Ich habe bewusst ziemlich übertrieben, das Wort "pervertiert" traf es schon ganz gut

[Gast]

aber ich verstehe nicht was die Bindings in der Konfiguration sollen. Gehst du davon aus, dass ein bzw. mehrere Config-Angaben in verschiedenen DI-Container-Elementen mehrfach vorkommen? Oder warum werden sie nicht direkt den Services zugeordnet?

Einmal das und zum anderen, damit diese Parameter nicht in der ganzen Konfigurationsdatei rumfliegen.

as heisst, einige Konstruktoren / Methoden von Klassen / Objekten, die Teil des DI-Containers sind, benötigen wiederum andere Klassen / Objekte aus dem DI-Container?

Richtig

[dsentker]

Okay, dann denke ich es verstanden zu haben. Vielen Dank.

[dr.e.]

Vorsicht mit Vergleichen zwischen decoration und dependency injection! Die beiden Pattern/Paradigmen sind nicht für den selben Zweck gedacht insofern kann hier nicht von "Präferenz" gesprochen werden.