nicht angemeldet
Hey dedlfix,
Er erklärt auch einige Dinge anders, als ich und als es mir geläufig war.
Findest Du? Für mich hört sich das fast genauso an wie das, was Du gesagt hast - oder wie ich Dich verstanden hab :-)Nicht grundlegend, aber in Details und Begrifflichkeiten.
ist zwar nicht wichtig, bin aber gerade trotz mehrfachen Lesens drüber gestolpert: Meinst Du,
er sagt grundlegend das gleiche wie Du, unterscheidet sich aber in Details und Begrifflichkeiten oder
er sagt nicht grundlegend das gleiche wie Du, aber Details und Begrifflichkeiten ähneln sich.
Ich gehe davon aus Du meintest ersteres.
Mir fällt immer wieder auf, was deutsch für eine schöne und differenzierte Sprache ist. Aber ich glaube gerade dadurch kommt es auch häufiger zu Mehrdeutigkeiten.
Wo ich das gerade schreibe fällt mir wieder die Geschichte ein, die uns unser Musiklehrer früher (mindestens tausendmal) erzählt hat, um uns klarzumachen, wie wichtig die Betonung in Musik und Sprache ist:
Ein Räuber soll gehängt werden und hat einen letzten Wunsch frei. Er wünscht sich der König möge ihn begnadigen. Ein Bote übermittelt dem König den letzten Wunsch und dieser anwortet: "Hängt ihn nicht, laufen lassen!" Der Bote rennt zurück zum Exekutionsplatz und ruft völlig außer Atem: "Hängt ihn, nicht laufen lassen!"
Das hat alles nichts mit Deiner Antwort oder dem Thema zu tun. Ist mir nur grad eingefallen und musste es einfach mal kurz niederschreiben :-)
Er hat sich ja mit den Frameworks schon beschäftigt, also wird auch seine Erklärung besser als meine sein.
"Besser" ist relativ. Seine Erklärung ist vielleicht fachlich genauer, Deine Erklärungen finde ich persönlich aber viel "besser". "Besser" in dem Sinne, dass es für mich verständlicher ist und das ich so mehr lernen kann. Und auch wenn mal was nicht hundertprozentig stimmt, lerne ich gerade dadurch noch mehr. Es gilt ja auch allgemein, dass sich "Fehler" besser einprägen - insbesondere, wenn man sich über Dinge austauscht und diskutiert.
Außerdem zeigen solche Tutorials nur allgemeine Wege auf. Deine Antworten beziehen sich aber direkt auf _meine_ Verständnisprobleme.
[Dependency Injection Container und DI-Frameworks]
Das muss ich mir nochmal genauer ansehen. So ganz erschließt sich mir noch nicht, wie das vonstatten gehen soll. Ok, dass, was ich z.B. in der test.php gemacht hatte [...]
kann ich natürlich auch in eine Klasse bzw. Klassen-Methode auslagern. Aber wie mich da ein Framework bei unterstützen soll, verstehe ich noch nicht. Außer vielleicht, dass diese Container in einer Registry abgelegt werden, sodass ich von überall aus darauf Zugriff habe.Für handverdrahtete DI sehe ich bei kleineren bis mittleren Projekten durchaus einen Sinn. Es nützt jetzt nicht übermäßig viel, wenn du keine Flexibilität bei der Abhängigkeitsauflösung benötigst, aber trotzdem ein DI-Framework einsetzt, das auf der einen Seite an deine Objekte angebunden werden muss und als großen Nachteil noch die Parameter, die deine Objekte so brauchen, an einer anderen Stelle konfigurieren musst. Damit hast du dann zwei Baustellen, die deine Aufmerksamkeit als Alleinunterhalter beanspruchen. Anders sieht die Sache im Team aus, wenn sich einer um die DI-Framework-Konfiguration kümmern kann und die anderen nur noch auf einfache Weise benötigte Objekte anfordern müssen.
Ok, also werden wir die Container erstmal hinten anstellen, die Objekt-Abhängigkeiten von Hand erstellen und gegen Interfaces implementieren.
Und ich werde mich weiter in das Thema einlesen.
Aber eine kurze Sache nochmal: Wie kann ich mir denn so ein DI-Framework vorstellen? Oder besser: Welche Vorteile bietet es mir? Ich stelle mir das immernoch so vor, dass ich auch in einem DI-Framework die Objekte von Hand erstellen muss - nur eben nur einmal innerhalb eines solchen Containers. Und anschließend kann ich aus dem gesamten Framework statt einer speziellen Klasse eben diesen Container aufrufen.
Gruß, Dennis