Diskussion:Dependency Injection

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Unverständlich 

message: 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)
thread_title:  Rod Johnson zu Dependency Injection 

message: 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).
: 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)
thread_title:  IoC 

message: 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)
replies: text: Setter Injection läuft über Reflection und nicht, weil die Klasse irgendwelche Interfaces implementiert. --Sebastian.Dietrich  ✉ 09:33, 27. Dez. 2013 (CET)
replies: text: 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)
thread_title:  Interface injection vs. Setter injection 

message: 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)
replies: text: @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)
thread_title:  Dependency Injection durch Multiple Inheritance in Python 

message: 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)
replies: text: @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)
thread_title:  Dependency Injection benötigt kein Framework 

message: 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)
thread_title:  Verlinkung