nicht angemeldet
Hey dedlfix,
Aber ich kann's nicht oft genug sagen: Danke für Deine Hilfe!
Das ist mir gegenüber nicht nötig. Ich entnehme den Dank implizit aus der Art und Weise, wie auf meine Postings reagiert wird. [...]
ich finde trotzdem, dass ich das immer wieder sagen kann und sollte. Dir im speziellen, aber auch vielen anderen hier im Forum (ich hoffe, die entsprechenden Stamm-Poster fühlen sich hier auch angesprochen, ohne dass ich sie jetzt im Einzelnen nenne).
Ich finde es echt super, dass Ihr Eure Freizeit opfert um Leuten wie mir zu helfen und an Eurem Wissen teilhaben lasst. Und das muss auch einfach irgendwie mal gewürdigt werden und sei es nur, dass ich mich bei Euch bedanke!
(Vorschläge natürlich sehr erwünscht): http://fsac.de/dat/selfhtml/library.zip
Aber Deine Hinweise haben mir trotzdem sehr geholfen (und ich bin froh, dass ich die neuere Version nicht hochgeladen hab - Du hättest wahrscheinlich nicht ruhig schlafen können :-) ).Ich soll doch nur kommentieren und nicht damit arbeiten, also hab ich auch keinen Grund, mich über eventuell vorhandene Missstände aufzuregen.
Dann bin ich zufrieden :-)
Ich hab jetzt unter oben genanntem Link mal eine neue Version hochgeladen, die ich eben mal gemacht habe. [...] aber vielleicht kannst Du mir kurz sagen, ob das jetzt Dependency Injection ist, was ich verwendet habe!?
Dazu hab ich selbst nochmal nachgelesen und bin zu dem Schluss gekommen, dass wir bisher nur darüber gesprochen haben, DI _möglich_ zu machen (ebenso Testbarkeit). Ansonsten haben wir immer Objekte zu Fuß erzeugt und die irgendeinem Konstruktor in die Hand gedrückt. Einen wesentlichen Aspekt von DI haben wir ausgelassen und das ist der Teil, der eigentlich die verschiedenen Komponenten zusammenbringt. Dieser Teil ist nämlich ausgelagert, ist in der Regel konfigurationsgesteuert und läuft so ab: Ein Objekt hat zum Arbeiten eine Abhängigkeit, braucht also ein anderes Objekt. Das DI-Framework kümmert sich nun darum, ein Objekt einer passenden Klasse zu instantiieren und zu übergeben, zu injizieren. Hört sich wieder eine Runde komplexer an, und das ist auch ein Kritikpunkt daran: Was da wie zusammenspielt wird nicht einfacher zu verstehen, wenn man dazu noch in eine zusätzliche Konfigurationsdatei betrachten muss.
Solange du jetzt aber nicht auch noch von deinem Aufgabengeber aufgetragen bekommst, DI richtig zu implementieren, denke ich, es reicht auch erstmal die Light-Variante mit den selbst instantiierten Objekten und ohne DI-Framework aufzusetzen. Dessen Vorteile müssen erstmal notwendig sein, um die zusätzliche Komplexität zu rechtfertigen. Auf alle Fälle verbaust du dir den Weg nicht, wenn du gegen Interfaces statt konkreter Klassen programmierst. Das widerspricht auch nicht dem YAGNI, falls ein DI-Framework gar nicht zum Einsatz kommt, denn die Trennung und lose Kopplung ist ja auch für die Testbarkeit und Erweiterbarkeit sehr hilfreich.
Deine Beschreibung ist zwar sehr schön und ich meine verstanden zu haben, worum es geht: Ich werde mich dazu aber erstmal noch was einlesen müssen. Das ist mir gerade noch "zu hoch". Wenn ich das was besser verstanden hab, komme ich aber gern auf Deine Hilfe zurück ;-)
Zum Institut: Es wurde nie "Dependency Injection" oder ähnliches in den Raum geworfen. Vielmehr haben wir uns selbst ein bisschen schlau gemacht, was es überhaupt als "Arbeitsgrundlage" so gibt. Ich weiß auch nicht, ob wir das jetzt tatsächlich mit DI oder was-weiß-ich umsetzen. Aber unabhängig davon interessiert mich das nach Euren Antworten jetzt. Vielleicht können wir das im aktuellen Projekt verwenden, vielleicht kann ich's später mal gebrauchen oder aber ich hab einfach für mich was dazugelernt.
Doch nun zum Code.
$loadHelper = new LoadHelperIni($file);
$config = new Config();
$config->load($loadHelper);
>
> Das (aus der test.php) sieht noch nicht nach DI aus, sondern eher nach herkömmlicher Arbeitsweise. load() will zwar keine bestimmte Klasse sondern nur irgendetwas, das das LoadHelperInterface implementiert hat, aber man braucht keine DI dazu, um die Vorteile von Interfaces nutzen zu können.
Genau dieser Unterschied war bisher wohl das größte Problem in meinem Verständnis von DI.
> Ein DI-Framework überwacht den Instantiierungsprozess und kann nur dabei die benötigten Abhängigkeiten auflösen. Beim load()-Aufruf kann das DI-Framework nichts mehr ausrichten. DI-fähig wird das Ganze, wenn du die LoadHelperInterface-Übergabe in den Konstruktor verlegst und die Config-Klasse sich selbst bedient, statt über load() angewiesen zu werden.
Ich bastel da noch ein bisschen dran rum und hoffe, ich kann Dir das nächste Mal dann wirklich DI präsentieren. :-)
> Jetzt noch zweimal Kleinkram bezüglich der Klasse Config:
>
> ~~~php
public function load(LoadHelperInterface $helper)
> {
> $configs = $helper->getConfigs();
> $this->add($configs);
> }
Hier tät ich mir den Zwischenschritt mit $configs sparen. Abgesehen davon, dass du es DI-gerecht umschreiben wollen wirst, wird die zweite Zeile nur ein Zeichen länger als die erste ist, wenn man es direkt schachtelt.
public function load(LoadHelperInterface $helper)
{
$this->add($helper->getConfigs());
}
>
> Alles, was man zusätzlich schreiben und lesen muss, ist Arbeit. Solange die Übersichtlichkeit nicht darunter leidet, kann man sich das ruhig sparen.
Wird erledigt!
> [...]
> ~~~php
if (is_array($value)) {
> $this->config[$name] = new Config($value);
> } else {
> $this->config[$name] = $value;
> }
Geht kürzer, und meiner Meinung nach auch übersichtlicher. Ziel ist ja, dass $this->config[$name] etwas zugewiesen wird. Das wird deutlicher sichbar, wenn es einmalig und am Anfang steht und dann der Trinitätsoperator verwendet wird.
$this->config[$name] = is_array($value) ? new Config($value) : $value;
Das halte ich persönlich auch für die bessere Schreibweise. Wir hatten uns aber darauf geeinigt, nur eine der beiden Schreibweisen konsequent zu verwenden. Aber wahrscheinlich ist das auch keine gute Wahl, nur (gezwungen) _eine_ Schreibweise zu verwenden. Ein (mit) ausschlaggebender Punkt war ein Artikel von Fabien Potencier zu dem Thema. Was meinst Du dazu?
Die eine Zeile ist (mir) übersichtlich genug, kann bei Bedarf aber auch als Dreizeiler ausfallen:
$this->config[$name] = is_array($value) ?
new Config($value) :
$value;
Die Schreibweise finde ich persönlich die schlechteste aller Varianten und werd mich damit wohl nie anfreunden können.
Gruß, Dennis