Programmierer A: Ey, ich injecte ein C durch constructor injection in mein B und das mache ich in dem ich von der Klasse namens "Injector" die Factory Funktion "new" verwende.
Programmierer B: Das B-Objekt wird von A mit dem B-Objekt als Konstruktorparameter instanziert.
Was macht mehr sinn? Es gibt bereits grundlegendere Begrifflichkeiten dafür, was hier passiert. Dass das vom Ürinzip her "auch schon" DI ist, ist lediglich ein Auftakt für Fowlers ausführungen. Und dass es wirklich DI ist, stelle ich in frage für alle sprachen, die keine Forwarddeklaration können. (Da gibt es kein "NOINN DAS IST NICHT SO" da gibt es nur ein "verstanden, warum ich das sage?")
Bei Programmierer B hast du was vertauscht (man kann es lesen als 'B wird mit B als Argument instanziert' oder 'A instanziert B und bekommt B als Argument', beides geht nicht), vermutlich sollte das ein "A wird mit einem B als Argument instanziert" sein?
Wie du selbst sagst: Ja, für ua. Fowler wäre beides DI.
Verstanden, was Forward Declaration damit zu tun haben soll, hab ich allerdings nicht. Genausowenig, warum das Einfluss auf DI hat.
Java nutzt man ohne Forward Declaration, du stellst also in Frage, dass es in Java DI gibt? Oder nur, dass ich das A, B, C- Beispiel so in Java implementieren könnte?
Abhängigkeiten existieren dabei ja auch nur in eine Richtung (B hat keine Abhängigkeiten, A nur zu B, C nur zu A un B), man muss nirgends Deklaration von Definition trennen.
Nicht nur für mich fängt DI da an, wo Objekte durch container gekapselt und anhand des Typs identifiziert werden, um sie durch schichten zu schleusen (injecten) die keine Abhängkeit (dependency) zu diesen Typen kennen.
Wie schon gesagt: den Fehler machen viele. Das DI oftmals mit DI-Containern gleichgesetzt wird, ist ein bisschen selbstverschuldet, da man DI nur selten wirklich ohne Container nutzt, möglich ist es aber.
Einfach nur stumpf ein A an ein B übergeben, wenn B ein A braucht, ist bereits DI, völlig ohne Container. Das wirst du auch in jedem Fachbuch und in nahezu jedem Artikel zu dem Thema so finden.
Wenn du meinst, dass das was ich service container nennen eigentlich ein service locataor ist, dann erkläre mir doch bitte, was dann ein service container ist. (Meine Implementierung hat wahrscheinlich aspekte von beidem)
Naja, service container ist eine Klasse von dir, deren Nutzung dem Service-Locator-Pattern entspricht. Ein eigenes Pattern "service container" gibt es nicht, zumindest ist es mir nicht bekannt und auf die schnelle auch nicht zu finden...
Es gab mal ein Bild mit etwa 40 pattern, die mit using/Extends in beziehung gesetzt wurden. Ich hab allerdings keinen Plan, wer dieses geniale Bild in die Welt gesetzt hat und wo es zu finden ist. Das sind für mich pattern, die du kombinieren, implementieren aber niemals (oder sehr selten wie beim observer pattern) (in basisklassen) kapseln kannst. Ich bin ziemlich sicher, dass in einem solchen Diagramm der ServiceLocator als "extends oder using di" auftauchen würde.
Du meinst so eins?
http://best-practice-software-engineering.ifs.tuwien.ac.at/patternmap.html
Wie gesagt: ServiceLocator ist keine DI, dazwischen gibt es weder eine "extends"- noch eine "using"-Beziehung.
DI-
Container und ServiceLocator haben durchaus Gemeinsamkeiten in der Implementierung, aber genutzt werden sie völlig unterschiedlich. Diese wäre in einem solchen Diagramm aber eher als DI "uses" Service-Locator eingezeichnet, da DI-
Container intern das Service-Locator-Pattern nutzen können.
Die uses-Beziehung in obigem Diagramm sind auch keine "muss immer nutzen", sondern ein "kann nutzen", die Besiegung von DI zu Abstract Factory und Container ist also nicht erzwungen. (Sieht man zb auch an "Facade uses Singleton", Facade kann ein Singleton nutzen, muss es aber nicht.)
Dass der Bohnen-DI-Container von Fowler "ServiceLocator" genannt wird. Aber ist er das wirklich?
Nein! eben darauf will ich nicht hinaus! "Bohnen-DI-Container von Fowler" wird
nicht Service-Locator gennant. DI (-Container) und Service-Locator werden völlig gegensätzlich genutzt, das ist in dem Artikel ziemlich gut dargestellt.
Und ja, die Unterscheidung ist durchaus wichtig.
(Mit "Bohnen" meinst du Beans? Das wird von Fowler dabei nur in dem Zusammenhang mit einer konkreten DI-Lösung verwendet, die eben als Beispiel für DI-Container und nicht für Service-Locator genutzt wird.)
Benutzt der ServiceLocator auch TypeIds und das Composite Pattern?
Beim Service-Locator kann mann intern nutzen, was man will. Es gibt da keinerlei Einschränkung bei der internen Implementierung, genausowenig bei DI-Containern.
Im übrigen nennt Microsoft es auch ServiceContainer.
ServiceContainer ist die Implementierung einer Registry, die als Service-Locator genutzt werden kann. Es ist aber kein DI-Container und führt auch keine Dependency Injection durch.
Ich weiß nicht wirklich, was du mit diesem Satz in diesem Kontext aussagen willst?
Es macht also wenig sinn, sich zu strikt an theorien zu halten, wenn die theorie besagt dass sie kombiniert und abgewandelt werden möchte. Dazu ist es ja auch geschmackssache. Fowler hat auch nicht die Wahrheit erfundern, beschreibt nur dinge mit seinen Begriffen die andere mit anderen belegt haben. .
Pattern gibt es in der Informatik nicht ohne Grund. Sie dienen auch (und nach manchen vor allem) dazu, Dingen einen Namen zu geben, unter dem jeder das gleiche versteht.
Man kann über Pattern nur reden, wenn man sich "strikt an theorien" hält. Und auch in der Implementierung, auch wenn man kombiniert und abwandelt, ist das Pattern immer eindeutig erkennbar. Wenn ein Muster nicht erkennbar ist, ist auch keins vorhanden - und ebenso: ist ein Muster erkennbar, ist es auch vorhanden.
Über Pattern reden, wenn jeder da etwas anderes drunter versteht, klappt nicht, sieht man ja gut an dieser Unterhaltung: ich versteh unter DI das Übergeben von Abhängigkeiten, du deine selbstentwickelte Lösung.
Es ist also nicht Geschmacksache, was man darunter versteht, sondern eine erste Definition ist Grundlage dafür, dass man es überhaupt nutzen und drüber reden kann.
Wenn es natürlich so ist, dass du meinst, Fowler hat genau das was ich mache, mit ServiceLocator benannt, macht es natürlich sinn, dass ich den begriff in zukunft übernehme.
Ja, das was du machst, ist Anwendung des Service-Locator-Patterns. Und Service-Locator ist etwas anderes als DI. Es
kann in der Implementierung von Service-Locator und DI-
Container Gemeinsamkeiten geben (DI-Container nutzen so intern durchaus Service-Locators), aber die Benutzung ist völlig Gegensätzlich.
Die Benennung als Service-Locator gab's übrigens auch vorher Fowlers Artikel schon, das stammt aus den Anfangstagen von JavaEE)