Diskussion:Dependency Injection

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Dependency Injection“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 90 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Unverständlich

Der Artikel ist in dieser Form nahezu unverständlich, es sei denn man weiß schon um was es geht. Aber dann schaut man eh nicht nach. -Gerdthiele 18:47, 17. Okt 2005 (CEST)

Absolut richtig. Ich habe den Artikel zweimal angefangen zu lesen und versucht ihn zu verstehen, aber es ist mir als nicht unerfahrener Tester nicht möglich. Eine Neustrukturierung ist hier sinnvoll! --212.64.228.100 10:03, 24. Jun. 2009 (CEST)

Sehe ich auch so. Ich verstehe es auch nach zweimaligem Lesen nicht. Besonders verwirrend sind, die Aussagen dass bei OOP Objekte die Implementierung anderer Objekte kennen müssen um sie zu erstellen. Das ist meiner Meinung nach GENAU das was man mit OOP vermeiden will. So denken viele. Also entweder ist die Aussage im Artikel falsch oder man muss genauer erklären. Außerdem ist auch unklar wieso man Daten in Konfigurationsdateien auslagern muss. Das ist nicht nachvollizehbar. 78.42.202.231 13:40, 11. Nov. 2010 (CET)

Der Satz "Fälschlich wird Dependency Injection in diesen Umfeld oft auch Inversion of Control genannt." ist IMO nicht ganz korrekt. Wenn ich Martin Fowler richtig verstehe, dann ist DI eher eine Spezialisierung von IoC: "As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.". BTW: in der englischen Wikipedia ist DI ein Redirect nach IoC ... Aber generell scheint man sich bzgl. der Abgrenzung zwischen den beiden Begriffen nicht so richtig einig zu sein. Habe einige Quellen gefunden, in denen beide Begriffe als Synonym angesehen werden. - Martin Herbst 11:32, 1. Nov 2005 (CET)

Quelltext: Bei "Injektion" denkt man an Ärzte. Die ständige Wiederholung von IAbhängigkeit ist da ganz besonders aufschlussreich. Eine völlig neue Perspektive! Empfehlung: Den Quelltext nicht lesen. Ist ja schrecklich m(93.230.97.23 (01:44, 19. Nov. 2016 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Quelltext: Quellcode mit deutschen Begriffen in einer englisch-geprägten Informatikerwelt und englischen Standardbegriffen ist extrem schwer lesbar für Leute mit Programmiervorkenntnissen (die sich wohl maßgeblich für solche Artikel und Prinzipien interessieren dürften). Meh. -- 93.104.174.90 14:39, 24. Jun. 2017 (CEST)

Rod Johnson zu Dependency Injection

Vielleicht hilft hier der englische Artikel zu Spring (Framework) von Rod Johnson weiter - http://www.theserverside.com/articles/content/SpringFramework/article.html. Einfach im Text nach "Dependency Injection" suchen. Immerhin nennt er sich als einer derer, die den Begriff geprägt hätten. Leider weiss ich nicht, ob man das hier wortwörtlich zitieren darf.

Wortwörtlich zitieren wird wohl bestenfalls zusätzlich möglich sein. In der deutschen Wikipedia erwartet man deutsche Texte. --80.153.250.36 13:23, 1. Sep. 2016 (CEST)

IoC

Inversion of Control bezeochnet einfach das Rückrufprinzip. Jeder Callback oder Event-/Observer-/Signal&Slot-Systeme sind eine Form von Inversion of Control. Immer wenn ich etwas nicht seblst Aufrufe, sondern jemandem etwas gebe, was dieser jemand dann aufruft habe ich IoC. oC ist also ein recht allgemeines Konzept. DI ist hingegen etwas spezielles. Ein Objekt hängt von einem Service ab. Statt sich selbst ein Objekt zu erstellen, das diesen Service bereitstellt (wodurch es an ein bestimmtes Objekt gebunden ist) bekommt es ein Objekt, dass diesen Service bereitstellt, von außen.

Ohne DI:

  class Foo {
     public Foo()
     {}
     ServiceInterface benötigterService = new KlasseDieDenServiceBereitstellt();
     public void methode()
     {
        benötigterService.erledigeDiesUndDas();
     }
  }

Mit DI:

  class Foo {
     public Foo(ServiceInterface benötigterService)
     {
        this.benötigterService = benötigterService;
     }
     ServiceInterface benötigterService;
     public void methode()
     {
        benötigterService.erledigeDiesUndDas();
     }
  }

Jetzt muss der Service von außen "Injeziert" werden (in dem Fall Konstruktor-Injektion).(nicht signierter Beitrag von 91.0.6.95 (Diskussion) 31. Mär. 2008, 14:30:03)

Ich würde eher sagen: Ein Klasse hängt von einem Service ab. Statt selbst eine Klasse zu verwenden, die diesen Service bereitstellt (wodurch es an ein bestimmte Klasse gebunden ist) verwendet sie eine Klasse, die diesen Service bereitstellt, von außen.

An ein ServiceInterface-Objekt ist ein Foo-Objekt immer gebunden. Ohne DI halt fest(selbstverantwortlich) und mit DI nur lose(über eine Referenz auf ein extern verwaltetes Objekt).

Das Wesentliche ist, dass das ServiceInterface jederzeit durch ein anderes ersetzt werden kann (bei Verwenden von Foo in einem völlig anderen Framework, beispielsweise, in dem die Klasse nicht KlasseDieDenServiceBereitstellt heißt, sondern bspw. ServiceProvider), ohne dass Foo entsprechend geändert werden müsste. --Geri, ✉ 21:07, 15. Mai 2011 (CEST)

Dependency Injection und Abstrakte Fabrik

Es geht um folgenden Absatz: "Das Bereitstellen konfigurierter Objekte entspricht dem Entwurfsmuster Fabrik. Frameworks implementieren dieses Muster mit umfassender Funktionalität, welche es in Weiterführung der ursprünglichen Idee erlaubt, Konfigurationen aus Dateien einzulesen und auf formale Korrektheit zu prüfen. Jedoch ist diese Funktionalität nicht alleiniger Bestandteil eines mit Dependency Injection in Zusammenhang gebrachten Frameworks." [1]

Dass DI Frameworks mittels AbstractFactory oder FactoryMethod DI implementieren halte ich für Theoriefindung. Bitte um einen Beleg. Der Satz "Das Bereitstellen konfigurierter Objekte entspricht dem Entwurfsmuster Fabrik" ist aber auf jeden Fall falsch, da eine Factory keine "konfigurierten" Objekte bereitstellt (das wäre schon eine Erweiterung der Factory).

Ebenso ist es nur eine Spezialform von DI Frameworks, wenn diese Konfigurationen aus Dateien einlesen & auf formale Korrektheit überprüfen. Guice arbeitet z.B. nicht so.

Ich hab den Absatz daher wieder reverted. --Sebastian.Dietrich ✉ 17:59, 4. Jan. 2013 (CET)

Hallo Sebastian,bislang ist folgendes klar, oder: Dependency Injection ist ein Setter- oder Konstruktoraufruf. Sind wir da einverstanden oder muss das verhandelt werden? (Immerhin musstest du nach deinem schnellen Ritt über meine lang durchdachten Änderungen diese Fakten sofort einarbeiten, anstatt zunächst Strittiges zu korrigieren und UnverzüglicH eine Diskussion zu eröffnen...)

Da die kurze Aussage in Bezug auf DI-Frameworks nicht alles sein kann (denn somit wäre ja jede OO-Software DI-Software): Was ist denn eigentlich die Gemeinsamkeit der Frameworks? Bieten sie denn alle oder mehrheitlich Funktionalität zur Objektkonfiguration und -bereitstellung, wie ich es von Spring kenne?

Denn es gibt zwei Phänomene: Der simple Vorgang und die (m. E. hach so tollen) Frameworks.

Übrigens Guice in allen Ehren, aber selbst Spring hatte ca. 2010 nach Jahren der Existenz noch keinen Projektanteil von 15%. Bitte orientieren wir uns an dem was üblich ist. EJB und Spring und was noch?

Also, du lernst beim Schreiben, wie im Profil zu lesen ist. Auf produktive Zusammenarbeit! --W. Klauber (Diskussion) 19:32, 4. Jan. 2013 (CET)

@DI = Setter oder Konstruktoraufruf. Ist nicht so. DI kann unterschiedlich implementiert werden. Siehe Abschnitt Umsetzung. Ich kann mir zu den 3 dort noch Reflection und Annotations vorstellen. Wo steht das denn überhaupt im Artikel?

@Absatz zu DI-Frameworks. Ja der gehört sicher noch erweitert. Ich vermute, dass die meisten DI-Frameworks nur DI können und nicht mehr - Spring ist da vermutlich die Ausnahme. Aber ist Vermutung und vermutlich nicht belegbar --> als Vermutung kommts in die WP nicht rein

@"Orientieren an dem was üblich ist" :-) Das geht in der WP leider nicht, weil "üblich" ist vermutlich nicht belegbar und Ansichtssache. Ich hab z.B. seit ca. 2005 nur mehr Projekte, wo Spring & Hibernate dabei war (und noch nie ein anderes DI oder Persistenz FW). Kann aber keine Aussage zu den 100.000 Projekten in Indien machen :-) Wir können nur schreiben "diverse", "einige", "gibt es auch", "unter anderem" etc. --Sebastian.Dietrich ✉ 20:05, 4. Jan. 2013 (CET)

DI = Setter oder Konstruktoraufruf. Ist nicht so. DI kann unterschiedlich implementiert werden. Siehe Abschnitt Umsetzung. Ich kann mir zu den 3 dort noch Reflection und Annotations vorstellen. Unterschiedliche Phänomene werden mit DI bezeichnet. Man kann DI m. E. nicht "implementieren". Oder falls doch: Bitte um Erläuterung. Auf Wiedersehen, bis morgen! --W. Klauber (Diskussion) 20:21, 4. Jan. 2013 (CET)

Ich denke nicht, dass DI unterschiedliche Phänomene bezeichnet. Di ist (wie der Artikel ja auch schreibt) einfach mal nur das Injecten von Dependencies. Die Frameworks können mehr bzw. müssen für den von ihnen gewählten Implementierungsansatz mehr können (z.B. das Erzeugen von Objekten). DI funktioniert aber auch z.B. ohne das Objekte dabei erzeugt werden müssen.

DI kannst natürlich auch selbst implementieren - also ein Modul, das von anderen Modulen deiner Software selbst nicht abhängig ist, aber Dependencies dort injekten kann. Quasi dein eigenes DI Framework. z.B. eine Klasse DependencyInjector mit der Methode inject(Object target, Object dependency, String referenceName), die mittels Reflection in target.reference die Dependency dependency setzt. targt kennt dependency nicht, sie wird ihm von aussen reingesetzt. Alle sind froh :-) --Sebastian.Dietrich ✉ 21:35, 4. Jan. 2013 (CET)

a) Also doch zwei Phänomene in einem Artikel: DI als solches, und Frameworks.

b) Vier mögliche Vorgehensweisen: Setter-, Konstruktor-, (Interface)Methoden-Injection und Injection via Reflection - oder?

b.1) Annotationen annotieren Methoden. D. h. fallen m. E. als eigenständiges Phänomen flach. (vgl. "Ich kann mir zu den 3 dort noch [...] Annotations vorstellen." Wie siehst du das?

c) Wie siehts du folgendes Aussage/Frage-Paar: "- also ein Modul, das von anderen Modulen deiner Software selbst nicht abhängig ist, aber Dependencies dort injekten kann." -> Nicht abhängig sein und gleichzeitig injecten zu können, heißt doch Injection mittels Reflection, oder?

d) Was machen denn DI-Frameworks mehrheitlich? Dienen Sie denn mehrheitlich der Bereitstellung von Objekten? --W. Klauber (Diskussion) 03:41, 5. Jan. 2013 (CET)

a) nein, der Artikel beschäftigt sich nur, aber umfassend mit DI. Die Infos zu den Frameworks sind (wie auch z.B. die Info zur Herkunft des Namens, die Infos zur Umsetzung nur ein Teilaspekt maximal ein Abschnitt wert. Der Artikel zu Deutschland enthält auch Infos zur Fauna in Deutschland. Das Phänomen ist Deutschland, Fauna ist "nur" ein Teilaspekt.

b) mMn ja - aber dass dies Info reinkommt benötigt es Belege. Wennst wo einen Artikel, Buch, etc. (aber nicht Blog) findest, der das besttigt, dann kann diese Info rein. Ansonsten nicht. Siehe WP:Belege

b.1) Schreib z.B. die Annotation @Injected für Attribute und schreib eine Hilfsklasse, die @Injected Attribute setzen kann. Die Hilfsklasse arbeitet zwar vermutlich mit Reflection (d.h. du hast schon recht, ist nicht eine 100% eigenständige Art), aber fühlt sich in der Verwendung anders an (d.h. schon als eigenständige Art erkennbar). Dasselbe gilt übrigens auch für Constructor und Setter Injection - die müssen ja auch intern Reflection verwenden, ansonsten kommt man nicht an den Constructor/Setter von Objekten ran, deren Klassen man nicht kennt.

c) Ja natürlich, das Modul verwendet Reflection um Dependencies zu injecten. Es macht somit DI mittels Reflection. D.h. du verwendest um DI zu machen ein Modul, das für dich DI macht. Wenn dir das zu weit geht, dann machst einfach das Modul inline - d.h. überall wo du DI brauchst machst selbst DI mittels Reflection.

d) DI-Frameworks machen alle DI. "Einige", "viele", "die meisten" machen das mittels Constructor/Setter zum Zeitpunkt der Instantiierung der Objekte. D.h. sie funktionieren nur über das Bereitstellen von Objekten und haben z.B. ein Problem damit, wenn die Objekte durch ein anderes Framework bereitgestellt werden (darum lässt sich Spring mit Hibernate nicht wirklich gut verheiraten). Dass sie also Objekte bereitstellen ist eher ein Mangel und weniger ein Feature von diesen DI-Frameworks. Besser wärs natürlich wenn man Objekte mit new erzeugen könnte, deren Dependencies dann aber bereits durch das DI-Framework gesetzt wären. --Sebastian.Dietrich ✉ 12:26, 5. Jan. 2013 (CET)

Ich hab die einleitenden Worte jetzt nach Deiner Änderung nochmals überarbeitet. Ich hoffe das passt jetzt. Wenn was noch unverständlich/missverständlich sein sollte, bitte um Diskussion... --Sebastian.Dietrich ✉ 13:06, 5. Jan. 2013 (CET)

Hallo Sebastian, finde gut, dass auf Fachtermini zu Beginn umgeschwenkt wird, ist aber m. E. für Außenstehende nicht zu durchdringen. Auch für mich stimmt der Satz jetzt weniger als mein Versuch von vorher. Es stört mich aber noch viel mehr, dass du das Single-Responsibility-Prinzip an dieser Stelle einfügst und nicht weiter unter. Aber ich empfinde es als Fortschritt, dass es offenbar erstmals in den Artikel aufgenommen wird. Meine Überarbeitung folgt später. Wünsche eine schöne Zeit, bis später! Ach ja: Unten müssen wird dann auch noch mal ran - solang du Nerven hast, gerne! --W. Klauber (Diskussion) 17:42, 5. Jan. 2013 (CET)

Hi - Fachtermini am Anfang ist dann OK, wenn sie verlinkt sind. Dann kann jeder der sie nicht kennt nachschauen, und diejenigen die sie kennen werden nicht mit kryptischen Umschreibungen in die Irre geführt.

@SingleResponsibilityPrinzip - ist ja nur in einem Nebensatz - d.h. kann gerne aus dem Satz raus und unten nochmals erwähnt werden. Der Rest des Satzes ist aber mMn in der Einleitung wichtig, da das der primäre Grund für DI ist

@stimmt jetzt weniger - bitte um Diskussion. mMn stimmt er mehr als vorher. Da bringt es nix es ständig hin-und-herzuändern. Sag mir was deiner Meinung nach falsch ist und wir diskuttieren vorher darüber und machen dann eine Änderung die für uns beide keine "Fehler" mehr hat.

@Rest des Artikels - gerne. --Sebastian.Dietrich ✉ 19:11, 5. Jan. 2013 (CET)

Ich habe zum Beispiel Probleme, mit Begrifflichkeiten wie "Abhängigkeiten SETZEN". Das sind weniger Fachtermini, sondern m. E. Entwickler-Slang. Ich bin aber trotzdem einverstanden mit dem ersten Satz, plädiere aber dafür, diese abstrakte Begrifflichkeit z. B. durch die anschließende Formulierung zu präzisieren: "Der Name Dependency Injection illustriert die Tatsache, dass in einigen ihrer Ausprägungen Referenzen durch Aufrufe auf das benötigende Objekt vermittelt werden. Im Kontrast zur Injizierung stehen Funktionsaufrufe durch das benötigende Objekt." Damit wird noch mal das "Setzen" aus dem einleitenden Satz in anderen Worten beschrieben. Und auch umfassender erklärt, was Injektion als Begriff bedeutet, da der Vergleich zum "Abhängigkeiten holen" getätigt wird. Überflüssig ist m. E. "Die Verwendung der Referenzen bleibt weiterhin..." Denk mal drüber nach. --W. Klauber (Diskussion) 13:05, 6. Jan. 2013 (CET)

@Abhängigkeiten setzen - was wär denn da deiner Meinung nach der Fachterminus?

@Satz - hab damit ein paar Probleme: "in EINIGEN ihrer Ausprägungen" ist mMn falsch, da das bei ALLEN der Fall sein muss. "Referenzen durch Aufrufe auf das benötigte Objekt VERMITTELT werden" - den Satz verstehe ich überhaupt nicht. Was heisst Referenzen "vermitteln"? Soll das ein Fachterminus sein? "Im KONTRAST zu ..." - stimmt mMn nicht. DI steht nicht im Kontrast zu Funktionsaufrufen. Ausserdem ist "Kontrast" irgendwie ungenau. ".. das BENÖTIGENDE Objekt" - ist mMn kein deutsches Wort. Würde es mit "das Objekt selbst" umschreiben. Ich sehe auch nicht den von dir angesprochenen Vergleich zum "Abhängigkeiten holen" in dem Satz erklärt (der Vergleich zu Abhängigkeiten holen ist mMn richtig - aber dann sollte der Satz auch "Die Alternative zur Injizierung ist das Holen der Abhängigkeiten durch das Objekt selbst." lauten).

@ "Die Verwendung der Referenzen bleibt aber weiterhin in der Verantwortung der Objekte" Ja können wir gerne streichen (mach ich gleich). Dachte dein Satz mit "Im Kontrast zur" soll irgendwie sowas aussagen - aber wie gesagt verstehe nicht was dein Satz sagen soll. --Sebastian.Dietrich ✉ 14:04, 6. Jan. 2013 (CET)

Hey Sebastian, schön, dass du so ausführlich antwortest und auf die betreffenden Stellen hinweist. Habe es gerade nur überflogen und finde diesen Satz richtig: "Die Alternative zur Injizierung ist das Holen der Abhängigkeiten durch das Objekt selbst." Wobei holen irgendwann später einer Detaildiskussion bedarf (Begründung, weshalb ich das denke, später). Ich guck mir jetzt noch mal alles an und setze meinen Entwurf der ersten Passagen hier auf die Diskussionseite. Das eröffnet uns die Möglichkeit, alternative Passagen untereinander zu stellen, vllt. erleichtert das die Ausarbeitung. --178.0.247.184 18:29, 6. Jan. 2013 (CET)

Naja, Planänderung.

@"Abhängigkeiten setzen. Ich glaube, "auflösen" ist beser.

@"In einigen ihrer Ausprägungen" mit Sicherheit unverständlich, wollte nur abgrenzen zur Injection via Reflection. Hatte ein falsches Bild von Reflection, ist ja aber auch ein Funktionsaufruf... Mein Fehler.

@"Im Konrast zu". Lies nochmal genau: "Der Name Dependency Injection illustriert die Tatsache, dass in einigen ihrer Ausprägungen Referenzen durch Aufrufe auf das benötigende Objekt vermittelt [aufgelöst] werden. Im Kontrast zur Injizierung stehen Funktionsaufrufe durch das benötigende Objekt." In der betreffenden Version sind die Worte auf und durch kursiv gesetzt... Ist aber eh alt. Aber nochmal zum benötigenden Objekt [selbst]. Habe ich absichtlich so formuliert um auszuschließen, dass man als Leser zufällig - innerhalb des aufgebauten gedanklichen Bildes - an das aufrufende Objekt denkt... Ist aber tatsächlich auch überflüssig, da vorher im Satz das Wort "Objekt" fällt. Dein Gedanke, stattdessen dass Wort "selbst" zu verwenden ist also absolut richtig, denn wenn man den Satz vergewissernd mehrmals liest, ist dann ausgeschlossen, dass man an was anderes, bspw. den Aufrufer denkt.

Ich für meinen Teil denke, wir haben's jetzt erstmal. Ich bin auf deine Änderungen, Anmerkungen gespannt. Und werde mich später den Hintergründen widmen. Bis dahin. --W. Klauber (Diskussion) 19:31, 6. Jan. 2013 (CET)

Aber lies du dir mal die Hintergründe durch und mach einen Vorschlag. Dann weiß ich was dir wichtig ist. Denn gerade jetzt würde mE nur der erste Satz stehen bleiben. --W. Klauber (Diskussion) 19:34, 6. Jan. 2013 (CET)

@Referenzen auflösen ist falsch. Unter Referenzen auflösen versteht man dass die Referenz gar nicht mehr existiert. Statt A -> B bekommst A, B. Nein "setzen" ist da schon das richtigere Wort. Was gefällt dir denn an dem Wort "setzen" nicht so richtig. Ich "setze" ja doch Attribute auf bestimmte Werte (in diesem Fall halt keine primitiven Attribute, sondern Referenzen auf andere Objekte).

@Funktionsaufruf - nein das ist es nicht. Mittels Reflection kann man Attribute direkt setzen, also die Referenz von A -> B direkt setzen ohne irgendeine Funktion aufzurufen.

Ich hab den Satz "Dabei ist die Referenz Argument eines Funktionsaufrufes - umgangssprachlich "von außen injiziert" - und nicht der Rückgabewert eines solchen." ganz gelöscht, da er mMn falsch ist. Die Referenz wird von aussen gesetzt - das kann über einen Methodenaufruf (setter-injection) passieren, muss aber nicht.

Dass der Satz zum Single Responsibility Prinzip runtergewandert ist finde ich sehr gut.

@Hintergründe - passen mMn alle so - ich würde da nix ändern. Was passt dir denn da nicht? --Sebastian.Dietrich ✉ 22:41, 6. Jan. 2013 (CET)

@"auflösen" ist falsch, ist mir vor 3min eingefallen... Wie wärs mit "übergeben"? Man spricht ja auch von Übergabeparametern... Ich starte mal einen Versuch.

@[den Satz ganz gelöscht] Ja, an der Stelle waren wir schon mal! Ich hatte formuliert im Sinne von [in einigen Ausprägungen] und wollte damit darauf hinweisen, dass sich der Name auf Vorgehensweisen bezieht, die nicht in allen Fällen verwendet werden, wenn man von DI spricht. Dass nicht alles Injektion ist, wo DI draufsteht, sollte uns keinesfalls hindern, darauf hinzuweisen, dass sich der Name von eben an die Charackteristik der Funktionaufrufe orientiert. (Reflection können wir unten ergänzen, im Sinne von: Manche DI-Framworks verwenden Reflection, so dass streng genommen der Name und dessen Sinnbildlichkeit nicht zutreffen. - vgl. Fowler, der Reflection auch nirgends erwähnt. Ist aber nicht so wichtig. Aber wenn es dich irritiert, wird es andere irritieren, also müssen wir das noch aushandeln. Aber vielleicht hast du es ja bereits verstanden? ) --W. Klauber (Diskussion) 01:02, 7. Jan. 2013 (CET)

@Hintergründe: "Dafür muss jedes Objekt einige Kenntnisse seiner Umgebung mitbringen, die es zur Erfüllung seiner eigentlichen Aufgabe normalerweise nicht benötigen würde. Insbesondere muss es, um die entsprechenden Objekte erzeugen zu können, ihre konkrete Implementierung kennen." Der zweite muss mE raus. Natürlich stimmt er, aber die konkrete Kenntnis der Umgebung wird nun auf ein DI Framwork oder ganz allgemein an einen äußeren Aufrufer verlagert. Somit erfasst der Satz mE nicht die Motivation für DI. Erkennst du, was ich meine?

@"übergeben" ist auch falsch, weil es nicht definiert, was der Übernehmer damit macht. Bei DI MUSS der Übernehmer nachher die Referenz gesetzt haben. Das Ziel ist, dass die Referenz gesetzt ist. Wie das erreicht wird ist nebensächlich. Daher ist mMn "setzen" die einzig richtige Beschreibung des Vorgangs. Was hast denn gegen setzen?

@Funktionsaufrufe. Woher hast denn die Vorstellung, dass DI was mit Funktionsaufrufen zu tun hat (bzw. "dass sich der Name von eben an die Charackteristik der Funktionaufrufe orientiert"). DI macht Injection von Dependencies - das hat nix mit Funktionsaufrufen zu tun. Es kann so implementiert werden, muss es aber nicht. Das Prinzip hat aber nix mit irgendwelchen Aufrufen zu tun. Nimm als Beispiel eine Firma mit Mitarbeitern und Vorgesetzten. Jeder Mitarbeiter kennt seinen Vorgesetzten. Mitarbeiter -> Vorgesetzter. Wer ist jetzt dafür Zuständig diese Referenz zu setzen? Darf sich der Mitarbeiter seinen Vorgesetzten selbst aussuchen? Wohl kaum. Das Umfeld (der Vorgesetzte, die Personalabteilung, der Vorgesetzte des Vorgesetzten, das Persistenzframework, wer auch immer) setzt dem Mitarbeiter seinen Vorgesetzten rein. Dependency Injection. In der DB steht z.B. beim Mitarbeiter der foreign key "supervisorId". Beim Laden würde ohne DI der Mitarbeiter selbst zu der supervisorId den entsprechenden Vorgesetzten suchen müssen. Die Klasse Mitarbeiter muss also wissen wo/wie sie zu einer supervisorId auf den Vorgesetzte kommt - "muss einige Kenntnisse seiner Umgebung mitbringen, die es zur Erfüllung seiner eigentlichen Aufgabe normalerweise nicht benötigen würde". Muss z.B. wissen ob sein Vorgesetzter konkret ein Abteilungsleiter, Projektleiter, Bereichsleiter, ... ist "muss, um die entsprechenden Objekte erzeugen zu können, ihre konkrete Implementierung kennen".

Die Motivation hinter DI ist, dass genau so etwas nicht passiert. Unsere Objekte sollen sich auf das konzentrieren, was sie selbst machen, und nicht darauf, wie sie sich ihre Referenzen zusammenbasteln. Genau dafür hat man DI, damit werden die Klassen kleiner, besser testbar, ... --Sebastian.Dietrich ✉ 10:03, 7. Jan. 2013 (CET)

@übergeben vs. setzen Nun gut, der Aufrufer setzt natürlich nicht! Und das Abstraktum von injizieren ist übergeben. Dass die passiven Objekte die Referenz nach Funktionsaufruf in einer Variable speichern (also "setzen") liegt außerhalb der Einflußnahme eines Aufrufers...! Sich darauf zu verlassen, dass der Übernehmner die Referenz ablegt also speichert ist lediglich Teil des Schnittstellen-Kontraktes, eine Zusicherung oder Nachbedingung des Methodenaufrufes. Also ist setzen einfach falsch.

@Funktionsaufrufe "DI macht Injection von Dependencies" - aber wie "macht" es die denn? Dass sind im Kern Funktionsaufrufe! DI ist lediglich ein Organisationsprinzip. Man "injiziert", also ÜBERGIBT Argumente (anstatt sie "holen" zu lassen (ein anderes Organisationsprinzip), das sind alles Funktionsaufrufe. Ob nun Konstruktor oder Setter. Egal, ob mittels Reflection oder nicht.

@Mitarbeiter/Vorgesetzter Das hat nichts mit DI zu tun! Das was du darlegst sind Überlegungen, wie Abhängigkeiten in einem System organisiert werden, und wer dafür verwantwortlich ist, Objekte zu erzeugen und zu übergeben. Der Begriff DI schärft lediglich das Bewußtsein für die Notwendigkeit und Vorteilhaftigkeit, Abhängigkeiten zu übergeben und das mittlerweile von zentralen, konfigurierbaren Komponenten, die Teil eines SOGENANNTEN DI-Frameworks sind. Injektion ist der Vorgang der Übergabe, und dass die Frameworks DI heißen, ist ein LABEL welches den Denkinhalt auslöst, dass mit ihrer Funktionalität Abhängigkeiten möglicherweise/sicherlich besser organisiert und verwaltet werden können. Allerdings ist Organisieren und Verwalten von Abhängkeiten nicht Dependency Injection. (Die Frameworks heißen zwar so, aber man konfiguriert mit ihnen die Abhängigkeiten... DI bedeutet aber nicht, Abhängigkeiten zu konfigurieren und zu organisieren, nur weil die Frameworks so heißen.) Injektion ist der wiederholte Vorgang beim Start, wenn Abhängigkeiten in einem Rutsch nacheinander übergeben werden. Deine Überlegungen bezüglich der Mitarbeiter betreffen das Design. Ich behaupte, mit der Aussage "Mach du mal die DI für unsere neue Software" kann niemand was anfangen. "Designe mal, und organisier die Abhängigkeiten." ist da präziser, entspricht im Kern deinen Mtarbeiter-Überlegungen. Hat aber noch gar nichts mit Injektion zu tun, ein Vorgang, der allein von einem technischen System vorgenommen werden kann. (Du schilderst menschliche Überlegungen - Die können keine Injektion sein!) Was meinst du?

@Hintergründe Erkenne etwas mehr durch deine anderen Infos. Werde ich mir Formulieruen zu überlegen. Ich reverte jetzt nicht wg. der Funktionsaufrufe, fordere dich aber auf, darüber nachzudenken und meine sätze bitte WIEDERHOLT zu lesen. Solange bis dir meine Argumentation einleuchtet oder etwas neues einfällt. Du selbst hast den Artikel ja erweitert um DI nach Fowler, du selbst erwähntest auch, dass DI u. A. mittels Reflection umgesetzt wird. Was bitte schön ist den der Kern dieser Konzepte? Doch wohl Funktionsaufrufe!!! Du hast heut morgen wieder mal die zwei Dinge vermengt: Auf welchen technischen Vorgang bezieht sich der Begriff? vs. Wozu verwendet man DI-Frameworks?

--W. Klauber (Diskussion) 16:24, 7. Jan. 2013 (CET)

@übergeben vs. setzen - Dependency Injection hat aber nix mit Kontrakt oder so zu tun. DI ist nur dann gegeben, denn die Dependency danach gesetzt ist. D.h. "Setzen" ist genau das richtige Wort. Wenn ich z.B. bei Spring mit setterInjection die Methode setVorgesetzter(supervisor) aufrufe, dann ist das nur dann wirklich DI, wenn diese Methode auch in die Variable vorgesetzter die Referenz auf supervisor reinsetzt. Der Methodenaufruf und die Übergabe der Referenz selbst ist belanglos, das einzige was zählt ist dass danach der Wert gesetzt ist.

@Funktionsaufrufe: Nein Funktionsaufrufe sind nur ein Hilfsmittel. DI ist das Injecten von Dependencies. Das geht auf unterschiedliche Art und Weise - auch wennst willst ohne einen einzigen Methodenaufruf (z.B. in C++ indem ich einen Pointer an einer bestimmten Speicheradresse setze). Ich vermute du verwechselst das WAS mit dem WIE. WIE DI gemacht wird ist nebensächlich, WAS DI macht ist wichtig. Und das WAS ist das Setzen von Referenzen in einem Objekt von ausserhalb des Objektes.

@Mitarbeiter/Vorgesetzter: Ich habe das Beispiel gewählt um darzulegen was die Überlegungen hinter DI sind. DI selbst ist ja nur das Setzen der Dependencies. Das erlaubt aber eben ein gänzlich anderes Design. Hier sind wir denke ich einer Meinung. Anmerkung: DI muss nicht beim Start einer Applikation passieren - das kann später auch noch der Fall sein, meistens beim Erzeugen der Objekte aber auch nicht unbedingt dann.

Ich denke wir sind vor allem hinsichtlich "setzen/übergeben" und "Funktionsaufrufe" uneins (siehe oben) Bei allem anderen verstehen wir uns zwar manchmal falsch, aber sind glaube ich dennoch gleicher/ähnlicher Meinung. Bitte korrigiere mich wenn du folgendes anders siehts:

• DI ist ein Konzept und kann auf unterschiedliche Art und Weise umgesetzt werden.
• DI hat als Ergebnis, dass eine Referenz nach der DI wo hinzeigt. --Sebastian.Dietrich ✉ 22:43, 7. Jan. 2013 (CET)

@"Der Methodenaufruf und die Übergabe der Referenz selbst ist belanglos, das einzige was zählt ist dass danach der Wert gesetzt ist.": Hallo? Der Methodenaufruf ist Kern der Metapher. Warum sonst schreibt Fowler: Es gibt ctor, setter-, interface-injection? Alles Methodenaufrufe!

@C++: Kannst du konkreter werden. ctor, setter, interface, reflection, jetzt plötzlich irgendetwas aus C++? Wie geht man bei dem von dir gemeinten C++ Framework vor?

@Korrektur: Sich zu einigen wird wahrscheinlich schwierig... Meine Version: DI ist lediglich ein Vorgang.

@Mitarbeiter/Vorgesetzter: Das Beispiel war eigentlich überflüssig, aber im Fluss des Schreibens hast du noch Folgendes erwähnt, in etwa [Kern der Framework-Idee, ist Abhängigkeiten zentral zu organisieren.] Insofern wieder bereichernd.

Abhängigkeiten zentral zu organisieren, ein Idee, meinetwegen ein Konzept. Das Wichtigste an den Frameworks ist mE die Organisation der Abhängigkeiten. (Klar werden dabei Funtkionen aufgerufen UND Werte in Variablen abgelegt.) Aber Methoden aufrufen und Variablen befüllen macht man ja auch sonst so - und nennt es nicht gleich DI. Deiner Interpretation nach, wäre ja alles was in einer gespeicherten Referenz mündet, DI!!!

@[als Ergebnis eine Referenz, die irgendwo hinzeigt]: Wie gesagt, passiert doch ständig. Ist aber nicht DI. Methode erzeugt Objekt (irgendwann muss sie ja mal selber ran, kommt doch nicht alles von außen.) Naja, ich lösch jetzt mal nicht, denn Folgendes. Meinst du etwa: Bei konsequentem DI gibt es nur noch injectede Member? Andererseits. Bleiben noch abgeleitete Member (Startup, irgendwas berechnen im Objekt, speichern). Wenn es sich um ein Objekt handelt, hätten wir im Ergebnis eine Refernz, die irgendwo hinzeigt, aber nicht injected wurde.

Soweit so gut, wieder neue Gedanken gehabt. Ich denke, der letzte Teil ist für uns beide erstmal am Interessantesten. Aber denk bitte an die C++ Sache. Was genau geht da vor?

--W. Klauber (Diskussion) 00:25, 8. Jan. 2013 (CET)

Hab nochmal in alten Beiträgen gelesen und folgendes von Dir gefunden:

"Quasi dein eigenes DI Framework. z.B. eine Klasse DependencyInjector mit der Methode inject(Object target, Object dependency, String referenceName), die mittels Reflection in target.reference die Dependency dependency setzt. targt kennt dependency nicht, sie wird ihm von aussen reingesetzt."

a)Meinst du wirklich target kennt dependency nicht? Oder nicht eher die Herkunft der dependency?

b)Wozu ist String referenceName im Beispiel gut?

c)Warum ruft der Aufrufer des Injectors, der ja sowohl target als auch dependency vorliegen hat, nicht einfach eine Inject-Methode auf target auf? Warum die Delegation an den Injector?

--W. Klauber (Diskussion) 02:30, 8. Jan. 2013 (CET)

<zurückrück>

• @ Methodenaufruf Kern der Metapher - ist er nicht. Fowler schreibt: "The basic idea of the Dependency Injection is to have a separate object, an assembler, that populates a field in the lister class with an appropriate implementation for the finder interface". Da steht nix von irgendwelchen Methodenaufrufen. Später schreibt er "There are three main styles of dependency injection." d.h. die 3 von ihm vorgestellten sind nur "styles of DI". Wie wir wissen gibt es noch weitere Arten (steht so im Artikel und ich hab 2 weitere genannt).
• @ DI ohne Methodenaufrufe. Beispiel: Mitarbeiter.manager soll via DI gesetzt werden: 1) mittels Reflection: myMitarbeiter.getClass().getDeclaredField("manager").set(myMitarbeiter, myManager); //keine Methode von Mitarbeiter wird aufgerufen 2) mittels PointerArithmetik: Manager* Mitarbeiter::*ptrToManagerAttribute = &Mitarbeiter::manager; myMitarbeiter.*ptrToManagerAttribute = myManager; //keine Methode von Mitarbeiter wird aufgerufen - schlag mich nicht, wenn die nicht auf Anhieb kompilieren, aber man bekommt beide auf jeden Fall zum Laufen
• @ Abhängigkeiten zentral zu organisieren - ja das ist die Idee der FRAMEWORKS. Die Idee der DI ist die Abhängigkeit zu entfernen, indem man sie von aussen setzt. D.h. wenn du mitarbeiter.manager von aussen setzt UND nachher Mitarbeiter von der konkreten Manager Implementierung unabhängig ist (d.h. ohne sie compiliert), dann hast du DI. Abhängigkeiten kann man auch anders entfernen (z.B. via ServiceLocator oder Publisher/Subscriber Pattern) und nur eine setManager Methode zu haben reicht nicht. Aber sobald du beides hast, hast du DI gemacht.
• @ Konsequente DI - ja, wenn man es konsequent macht, dann werden alle Referenzen von aussen gesetzt und die Klassen kennen einander nicht mehr (sondern nur ihre Schnittstellen). Üblicherweise wird das auch an Komponentengrenzen/Schichtengrenzen so empfohlen - d.h. jede Komponente/Schicht definiert die Interfaces ihrer Facade, andere Komponenten/Schichten kennen nur diese Interfaces und bekommen zur Laufzeit die konkrete Implementierung dieser Interfaces injected. Damit kann ich jederzeit z.B. zu Testzwecken Implementierungen von Komponenten/Schichten austauschen.
• @ Alte Beiträge: Hier ausprogrammiert (sollte denke ich deine Fragen klären):

class Mitarbeiter { //Mitarbeiter kennt das Interface Manager aber nicht die konkrete Implementierung
  private Manager manager; //private ohne setter (um zu beweisen, dass es ohne Methodenaufrufe geht)
  //was auch immer Mitarbeiter sonst noch hat, aber nirgendwo wird manager gesetzt
}

class DependencyInjector { //unser "Framework", kennt keine der anderen Klassen
  public static injectDependency(Object target, Object dependency, String referenceName) {
    target.getClass().getDeclaredField(referenceName).set(target, dependency);
  }
}

interface Manager {
  ...
}

class Abteilungsleiter implements Manager { //die konkrete Implementierung
  ...
}

class Test {
  public static void main(String[] args) {
    //Reflection Injection
    Mitarbeiter mitarbeiter = new Mitarbeiter();
    DependencyInjector.injectDependency(mitarbeiter, new Abteilungsleiter(), "manager");

    //Constructor Injection (nur wenn es einen entsprechenden Constructor in Mitarbeiter gäbe)
    Mitarbeiter mitarbeiter = new Mitarbeiter(new Abteilungsleiter());

    //Setter Injection (nur wenn es einen entsprechenden Setter in Mitarbeiter gäbe
    Mitarbeiter mitarbeiter = new Mitarbeiter();
    mitarbeiter.setManager(new Abteilungsleiter());
  }
}

Das wichtigste ist wie gesagt, dass danach mitarbeiter.manager auf den Abteilungsleiter zeigt OHNE dass die Klasse Mitarbeiter die Klasse Abteilungsleiter kennt. --Sebastian.Dietrich ✉ 10:58, 8. Jan. 2013 (CET)

@"@ Methodenaufruf Kern der Metapher - ist er nicht. Fowler schreibt: "The basic idea of the Dependency Injection is to have a separate object, an assembler, that populates a field in the lister class with an appropriate implementation for the finder interface". Da steht nix von irgendwelchen Methodenaufrufen. Später schreibt er "There are three main styles of dependency injection." d.h. die 3 von ihm vorgestellten sind nur "styles of DI". Wie wir wissen gibt es noch weitere Arten (steht so im Artikel und ich hab 2 weitere genannt)."

Ja, aber die drei main styles nutzen doch alle Methodenaufrufe 27x!!!!!!!!!!

So wie es aussieht, finden wir keinen Grund, warum das nun injection heißt...

Oder hast du mittlerweile eine Erklärung für die Namenswahl?

--W. Klauber (Diskussion) 14:42, 8. Jan. 2013 (CET)

Ja klar nutzen sie Methodenaufrufe. Sie nutzen aber auch Objekte, Klassen, Interfaces, etc. Das Nutzen von Methodenaufrufen ist (so wie das Nutzen von anderen Dingen) nur Mittel zum Zweck. Und wie beschrieben geht DI auch ohne Methodenaufrufe, d.h. Methodenaufrufe sind weder notwendiger, noch zentraler Bestandteil der DI.

Wusste gar nicht, dass deine Frage lautet "Warum das 'injection' in dependency injection?". Ist für mich schon klar: Weil Injection klar macht, dass das Objekt die Dependency nicht selbst setzt, sondern sie von aussen gesetzt wird. So wie SQL-Injection, wo von aussen SQL Code eingeschleust wird. (detto email- oder code-injection).--Sebastian.Dietrich ✉ 23:22, 8. Jan. 2013 (CET)

Ja, das ist eigentlich lustig. Wir drehen uns um folgendes m. E.: Dein Begriff, den du dir von Injection gemacht hast, ist "von außen setzen". Mein Begriff ist eher: "übergeben".

Für dich eher wie Einschleusen?

Und wenn du mal folgendes denkst: Definiert einfüllen im Sinne von Spritzen?

Folgendes ist bekannt: Fowler nennt ctor, setter, interface. Alles im Sinne von einfüllen, übergeben (Argument eines Methodenaufrufes). Das ist m. E. die initiale Wortbedeutung. Die im Laufe der Zeit erweitert worden ist.

Wie denkst du dazu?

--W. Klauber (Diskussion) 01:05, 9. Jan. 2013 (CET)

Ja anscheinend ist das der Kern unserer Meinungsverschiedenheit. Ich denke an Injection im Sinne von (siehe Übersetzung von Injection) Injektion, Einspeichern, Einspritzen, Einpressen. Eine Spritze "setzt" ja auch ein Medikament von aussen (durch jemand anderen) in den Körper. Du denktst an Injection im Sinne von Übergeben (was weit von jeder Übersetzung von Injection entfernt ist) - Pillen wären mehr im Sinne von Übergeben als Injektionen. Pillen "gibt" man dem Patienten, der sie dann selbst einnimmt/schluckt. Wäre das Übergeben der Kern der Sache, würde es "Dependency Delivery" oder so heissen.

Frage 1: Ist für Dich DI gegeben, wenn nach dem ctor, setter, interface, die Dependency NICHT gesetzt wäre? z.B. public void setManager(Manager manager) { manager.addMitarbeiter(this); /*don't store dependency to manager*/ } Ich vermute nicht -> der Kern der Sache kann nicht der Methoden/Konstruktoraufruf bzw. dessen Parameter sein.

Frage 2: Ist für Dich DI gegeben, wenn wie beim C++ und Reflection Beispiel keine Methoden aufgerufen werden, aber danach Mitarbeiter die konkrete Manager Implementierung nicht kennt und dennoch die Referenz auf einen konkrete Abteilungsleiter gesetzt ist? Ich vermute ja.

Der Artikel von Martin Fowler erklärt WAS dependency injection ist und WIE man es implementieren KANN (aber nicht muss). Nur weil er bei den Implementierungen Methoden verwendet heisst das nicht, dass dependency injection nur mit Methodenaufrufen funktioniert. Das hat auch Fowler nirgendwo gesagt. Und es gibt Techniken & vermutlich sogar auch Frameworks, die DI OHNE Methodenaufrufe machen. --Sebastian.Dietrich ✉ 08:22, 9. Jan. 2013 (CET)

Worauf sich das Injektion heute bezieht, haben wir wohl in der Diskussion geklärt. Vielleicht sollte man das für den Artikel zusammenfassen.

Was den Grund der Benennung betrifft, befinden wir uns wohl in einer WP:TF, denn niemand von uns beiden weiß, woran Fowler bei "Injection" gedacht hatte, d.h. an welcher Stelle der beschriebenen Phänomene er die Injektion erkannt hat (Ich vermute ja, Parameterübergabe ist seines Erachtens nach Injection, im Vergleich der bis dato ebenso selbstverständlich üblichen Rückgabe von Abhängigkeiten)...

Mir liegt schon daran, die Wortherkunft mit unterzubringen. Ich mache mal einen Entwurf im Artikel in neutraler Formulierung ohne Vermutungen vorzubringen. Vielleicht ist das ja für dich auch akzeptabel.

--W. Klauber (Diskussion) 15:03, 9. Jan. 2013 (CET)

Hi! Der Entwurf ist zwar neutral formuliert (+1), aber über eine nicht belegbare Wortherkunft überhaupt einen Absatz zu schreiben halte ich für falsch. Also insgesamt -1. Das einzige was Fowler zur Wortherkunft sagt stand schon da "... we settled on the name Dependency Injection" (keine Erklärung warum "dependency" und warum "injection" und nicht z.B. "reference setting") - jede weitere Info zur Wortherkunft wäre falsch, weil Fowler eben nichts weiteres dazu gesagt hat.

Ich hab aber den von dir geschriebenen Absatz runterkopiert zur Umsetzung und dort mit dem bereits bestehenden Text vermantscht. Hoffe das ist für dich akzeptabel. --Sebastian.Dietrich ✉ 22:08, 9. Jan. 2013 (CET)

Na der Witz an der Sache war, dass man sich über die WortBEDEUTUNG, nicht Herkunft, allein seine Gedanken hätte machen können... Verweis, darauf, das im Dokument von Fowler nur Methodenaufrufe vorkommen + anschließende Aussage, das heutige Frameworks mehr machen...? War doch gut.

--W. Klauber (Diskussion) 22:16, 9. Jan. 2013 (CET)

Alleine schon, aber das war eine Denk-Unterstützung in eine bestimmte Richtung. Eine Richtung, von der nur einer von uns beiden überzeugt ist, dass sie Fowler angedacht hat. Genausogut könnte man in meine Richtung dort Philosophieren, dass "Injection" in der Informatik geerell wie bei z.B. "SQL Injection" bedeutet, dass man was ohne zutun des anderen ihm injiziert (im Gegensatz zu ihm brav mit einem Methodenaufruf übergibt). Das wäre eine Denk-Unterstützung in genau die andere Richtung und genauso fehl hier am Platz (auch wenn wiederum einer von uns überzeugt ist, dass sie Fowler angedacht hat. Denk-Unterstützung in nicht belegte Richtungen sind in der WP aber nicht ok. --Sebastian.Dietrich ✉ 23:04, 9. Jan. 2013 (CET)

Komm schon, dass man sich was vorstellen kann, ist doch wohl wichtig? Außerdem kam klar die Überleitung auf weitere Vorgehensweisen zeitgenössicher DI. Kann man sich doch als Leser selbst entscheiden, wie weit man den Begriff Injection im Zusammenhang mit Dependency fasst, oder?

Und SQL Injection ist ja mal was ganz anderes. Das Injektion hier muss ja nicht zwangsläufig dem Injection dort entsprechen.

So, mein letztes Wort. Denk drüber nach. Bau es wieder rein. Ich schau noch mal vorbei.

--W. Klauber (Diskussion) 23:25, 9. Jan. 2013 (CET)

Nein, bitte bau es nicht wieder rein, sonst bau ich es wieder aus. Es ist Theoriefindung, auch wenn es nur angedeutet wird. Du kannst aber gerne Martin Fowler eine email schreiben, ob er ursprünglich mit Injection die Übergabe von Parametern an Methoden gemeint hat. Kann ich mir zwar nicht vorstellen, weil das ja dann das völlig falsche Wort ist, aber wenn ers so gemeint hat, dann kommts (mit Beleg) rein. Ansonsten bitte keine eigenen Interpretationen - auch wenn nur angedeutet. --Sebastian.Dietrich ✉ 12:20, 10. Jan. 2013 (CET)

Sebastian, ehrlich! Das illustriet eine gewisse Nachlässigkeit deinerseits. Da steht doch klar zur Interpretation dargeboten, dass ich nicht derjenige sein werde, der die Änderung vornimmt!!! Sei bitte etwas aufmerksamer. Ich denke, dass du einen guten Überblick über Software etc. hast, ich denke aber nicht, dass du deshalb gleich derjenige sein solltest, der hier bestimmend agiert - dein Hervorbringen und Interpretieren von Worten ist m. E. einer Enzyklopädie noch unangemessen. Natürlich sehe ich aber einen Fortschritt im Artikel, der nur durch mich und dich gemeinsam errungen wurde. Trotzdem ist es schwierig für mich, optimistisch weitere Passagen in Angriff zu nehmen, wenn selbst Änderungen, die m. E. mit allem, was so gefordert ist, harmonieren, vor dir keinen Bestand haben.

Aber trotzdem, vielleicht geht's ja weiter. Ich habe bei M. Fowler angefragt. Scheint aber zu dauern. Bis später!

--W. Klauber (Diskussion) 16:31, 11. Jan. 2013 (CET)

@Interpretation "Bau es wieder rein" kann man als Aufforderung sein - ich habs als Verkürzung für "(Ich) bau es wieder rein" gesehen. Sorry.

@Bestimmendes Agieren. Sorry wenn das so angekommen ist. Aber du hast schon recht - jeder schreibt immer so, dass man zumindest zwischen den Zeilen dessen Meinung etc. lesen kann. z.B. wo im Artikel steht was über die Nachteile von DI? Ich kenne eigentlich keine, aber vielleicht gibt es welche. Ich suche aber auch keine, weil ich eben biased bin. Das gilt aber auch für dich und für jeden anderen. Darum ist in der WP besonders spannend wenn mal unterschiedliche Meinungen aufeinanderprallen - dafür gibts aber im Notfall sowas wie WP:3M. Die können wir immer noch anrufen, wenn wir uns nicht irgendwo einigen.

Ich denke auch, dass der Artikel jetzt (gemeinsam) besser gemacht wurde, als er davor war. Das WikiPrinzip funktioniert also auch dann, wenn man nicht einer Meinung ist. Dass du bei Fowler angefragt hast ist super. Meine Erfahrung bezüglich Anfragen bei "prominenten" Informatikern ist aber leider eher negativ. Egal wie agil und kommunikativ sie sich geben, email scheint kein Instrument für die Kommunikation mit ihnen zu sein. Hoffen wir aber das beste... --Sebastian.Dietrich ✉ 23:14, 11. Jan. 2013 (CET)

Schön, dass du antwortest. Was ich ausdrücken wollte, ist: Du bist eine wertfolle Informationsquelle, aber deine Änderungen haben mir schon Sorge bereitet, hinsichtlich der Formulierungen. Was meinen letzten Vorschlag angeht. Nimm ihn dir halt noch mal vor, lass ihn dir mehrmals im Hirn und auf der Zunge zergehen, und dann frag, dich, ob er die Vorstellung bezüglich Injection tatsächlich auf Funktionen fixiert. Darum gings ja. Und nein, die Passage ist keine TF. Sie schildert nur, dass was Fowler vorbringt (und deutet an, dass er daran gedacht haben könnte, an Funktionsargumente) und schildert dann, was heute unter Injection getrieben wird. Hätten wir beides: Objekte Berichterstattung (kann halt jeder selber für sich entscheiden, ob Fowler NUR an Argumente gedacht, oder nicht) + Information zum aktuellen Injection-Begriff. Denn die Frage taucht doch sicher auf: Warum heißt dass den nun Injection? Also, noch mal den Vorwurf von vorhin aufgreifend. Lies genauer. Lies noch mal die Passage, die du gestrichen hast; ich denke, sie entspricht uns beiden und sollte als Ergebnis der 2-3 tägigen vorhergenden Diskussion stehen bleiben... Si?

Notfalls zur 3M.

--W. Klauber (Diskussion) 00:09, 12. Jan. 2013 (CET)

Hi! Du schreibst in dem Absatz: "Alle von ihm geschilderten Verfahrensweisen machen dabei Gebrauch von Methodenaufrufen, [..]". Ja das fixiert Injection nicht auf Methodenaufrufe, aber stellt es als deutlichen Hinweis in den Raum. Stell dir vor der Absatz würde nicht den Gebrauch von Methodenaufrufen, sondern die Verwendung von Hilfsklassen rausstreichen: "Alle von ihm geschilderten Verfahrensweisen machen dabei Gebrauch von Hilfsklassen, [..]". Wärst Du damit glücklich? Würde das nicht implizit aussagen, dass DI lt Fowler damals Hilfsklassen benötigt? Ich bin mir 100% sicher, dass Fowler damals weder andeuten wollte, dass DI was mit Methodenaufrufen, noch was mit Hilfsklassen am Hut hat. Alleine das Herausstreichen von Methodenaufrufen (oder Hilfsklassen) ist bereits eine Andeutung dafür, dass A mit B etwas gemein haben könnte. Darum sollte im Absatz Wortbedeutung nix von Methodenaufrufen (oder Hilfsklassen) stehen - sondern wenn überhaupt dann woanders (ich habs ja nicht gelöscht, sondern nur nach Umsetzung verschoben). --Sebastian.Dietrich ✉ 12:10, 12. Jan. 2013 (CET)

Aber die Hilfsklassen erinnern doch nicht an den Vorgang einer Injizierung! Die Frage ist doch: Warum dieses Wort? Und das hatten wir doch alles erklärt! Es geht doch nicht darum, was DI benötigt, sondern woran sich das Wort "Injection" orientiert. Injection ist eine Metapher. Aber weshalb wurde diese Metapher gewählt? Für dich ist klar, und offenbar ist das die Bedeutung, die allen Entwicklern tatsächlich auch vorschwebt: Setzen von außen. Und all die Vorgehensweisen, die mit Setzen von außen bildlich in Einklang zu bringen sind, standen im Abschnitt drin.

Aber warten wir ab.

--W. Klauber (Diskussion) 15:40, 12. Jan. 2013 (CET)

Interface injection vs. Setter injection

Verzeihung, aber da sehe ich keinen Unterschied. In beiden Fällen handelt es sich um eine Implementierung eines Interfaces und in beiden Fällen wird die Abhängigkeit über eine Methode injectet. Das ist für mich eine Setter Injection. Wenn man über die Tatsache dass es ein Interface ist mehr aussagen möchte, sollte man das Code Beispiel anpassen. --BuZZa (Diskussion) 16:57, 26. Dez. 2013 (CET)

Setter Injection läuft über Reflection und nicht, weil die Klasse irgendwelche Interfaces implementiert. --Sebastian.Dietrich ✉ 09:33, 27. Dez. 2013 (CET)

Also ich sehe immer noch den Unterschied zwischen den zwei Beispielen aus dem Artikel. Kannst Du das vielleicht nochmal freundlicherweise ein bisschen erklären? Ich sehe leider auch nicht, wie Setter Injection etwas mit Reflection zu tun hat. Danke, --2.162.120.112 20:30, 20. Mär. 2014 (CET)

Codebeispiel "Interface Injection" korrekt?

Anmerkung zum Abschnitt "Interface Injection" zu demjenigen Teil des Codebeispiels, welcher das Injizieren durchführt. Sollte es statt

  class Injizierer {
    void methode() {
      Injizierbar injizierbares = ... ;
      Abhängigkeit abhängigkeit = ... ;
      injizierbares.injiziere(abhängigkeit);
    }

nicht folgendermaßen lauten (also ganz analog zum Beispiel in "Setter Injection"):

  class Injizierer {
    void methode() {
      Abhängiges abhängiges = ... ;
      Abhängigkeit abhängigkeit = ... ;
      abhängiges.injiziere(abhängigkeit);
    }

Objektorientierung?

An mehreren Stellen wird erwähnt, dass es sich bei DI um ein OO Konzept handelt. DI ist aber soweit ich das sehe nicht auf OO beschränkt --> gehört im Artikel breit umgestellt... --Sebastian.Dietrich ✉ 16:33, 15. Dez. 2014 (CET)

Sebastian.Dietrich: Hast Du reputable Quellen hierzu? Die mir bekannten Quellen stellen DI immer mit Bezug zu OO oder als OO-Konzept vor. --Eff0ktiv (Diskussion) 00:05, 18. Nov. 2015 (CET)

Ich denke nicht dass es Quellen benötigt aufzuzeigen, dass DI nicht nur für OO möglich ist (wenn dann umgekehrt: Quellen, die behaupten, dass DI nur mit OO möglich ist).

Überleg mal: Nicht nur in OO gibt es Dependencies, warum sollte es ausserhalb der OO nicht möglich sein Dependencies zu Injecten? --Sebastian.Dietrich ✉ 08:32, 18. Nov. 2015 (CET)

Unsere Aufgabe in der WP ist es, etabliertes Wissen darzustellen, nicht, uns selbst zu überlegen, wo DI überall noch angewendet werden könnte. Das wäre WP:TF. Überleg mal, das Manjisai beispielsweise kann man sicherlich auch bei anderen Kampfkünsten als dem Kobudō gut gebrauchen, trotzdem bleibt es doch eine Kobudō-Waffe, solange es außerhalb von Kobudō keine Verwendung findet. Grüße, --Eff0ktiv (Diskussion) 23:55, 23. Nov. 2015 (CET)

Ja - ist es denn etabliertes Wissen, dass DI ein OO Konzept wäre? Ja ist sicher bei Projekten, die OO Sprachen verwenden erstmals so genannt worden und auch die ersten DI-Frameworks sind für OO Srachen entstanden. Aber ist es deshalb ein OO Konzept? Dann wäre agile Softwareentwicklung auch ein OO Konzept. Du meintest, dass die dir bekannten Quellen DI immer mit Bezug zu OO oder als OO-Konzept vorstellten - kannst du diese bitte hier zitieren und im Artikel als Referenz zu OO angeben? Ich mach mich inzwischen auf die suche nach DI-Frameworks/Literatur für nicht-OO Sprachen. --Sebastian.Dietrich ✉ 16:13, 4. Dez. 2015 (CET)

Schau Dir am besten erstmal die bereits jetzt im Artikel verlinkten Referenzen an. --Eff0ktiv (Diskussion) 19:48, 4. Dez. 2015 (CET)

Hab ich getan - sie verwenden zwar alle OO, aber keiner davon spricht davon, dass DI ein OO Konzept wäre. --Sebastian.Dietrich ✉ 12:12, 5. Dez. 2015 (CET)

Wenn alle Quellen sie ausschließlich im Kontext OO vorstellen, dann handelt es sich offensichtlich um ein OO Konzept. Triviale Aussagen erfordern keine Belege, siehe WP:BLG. Grüße, --Eff0ktiv (Diskussion) 02:09, 7. Dez. 2015 (CET)

Dependency Injection durch Multiple Inheritance in Python

In Python ist es möglich von mehreren Klassen zu erben, wobei die Method Resolution Order (MRO) definiert welche Methoden von welcher Klasse geerbt werden zu einem bestimmten Zeitpunkt. Die MRO geht immer zuerst vom untersten Kind aus, dann werden die Eltern des Kindes nacheinander gelistet und dann erst die Eltern der Eltern. Dadurch wird es möglich systematisch das Diamond-Problem für Dependency Injection auszunutzen. So ist es z. B. möglich eine Methode von A die von B geerbt wird durch einen Mock fürs Testen zu ersetzen, indem eine Mock-Klasse C(A) mit der zu ersetzenden Methode geschrieben wird. Zuletzt wird eine leere Klasse D(B, C) geschrieben, welche zunächst alles von B erbt, dann wird die gewünschte Methode von C übernommen und der Rest kommt von A. Ein ausführlicher Talk über "super()", also der Funktion zum Aufruf der nächsten Klasse in der MRO (*nicht* unbedingt die Elternklasse!) gibt es von Raymond Hettinger auf Youtube --Amogorkon (Diskussion) 16:18, 30. Apr. 2015 (CEST)

@Amogorkon: Wenn das in Python keine gängige Umsetzung von DI ist, ist es enzyklopädisch nicht relevant. --Eff0ktiv (Diskussion) 00:02, 18. Nov. 2015 (CET)

Dependency Injection benötigt kein Framework

An diversen Stellen des Artikels wird deutlich, dass davon ausgegagnen wird, dass Dependency Injection nur mit Hilfe von Frameworks umgesetzt werden kann. Ganz allgemein beschrieben beschreibe Dependency Injection nur, dass die Abhängigkeiten eines Objekts nicht von diesem selbst erzeug oder ermittelt werden, sondern von außerhalb des Objekts zur Verfügung gestellt werden. Daraus folgt, dass es völlig unerheblich ist, ob die Abhängigkeiten an einer zentralen Stelle verwaltet werden. Ebenso benötigt die Setter-Injection nicht zwingend Reflection, was aber hier auf der Diskussionsseite aber in einem Beitrag beschrieben wurde. --Richard Wepner (Diskussion) 10:23, 26. Jun. 2015 (CEST)

@Richard Wepner : Welche Formulierungen genau beanstandest Du? Ich kann nicht erkennen, dass der Anschein entsteht, das DI ein Framework zwingend benötigen würde. --Eff0ktiv (Diskussion) 23:59, 17. Nov. 2015 (CET)

Verlinkung

Ich bin über den Begriff "Architekturmuster" auf den hier behandelten Begriff "Dependency Injection" verwiesen worden. Und hier lese ich gleich ganz oben, dass "Depedency Injection" ein Entwurfsmuster wäre.

- Was ist es denn nun, Entwurfsmuster, Architekturmuster oder doch nur ein Prinzip?

Bitte die Verlinkung entsprechend anpassen. (nicht signierter Beitrag von 92.211.55.193 (Diskussion) 14:30, 6. Aug. 2016 (CEST))