Diskussion:Dependency Injection

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) Beantworten

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) Beantworten

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)

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.

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).

HiveMind wurde von Apache als "retired" in den "attic" verschoben und statt dessen empfiehlt Apache ihr Tapestry-Projekt, dass allerdings einen Servlet-Container (wie tomcat) voraussetzt. Ggf sollte HiveMind gestrichen und Tapestry ergänzt werden. Sehr nützlich wären auch die links zu den jeweiligen Projekten ;-) ~~---- (nicht signierter Beitrag von 109.85.102.245 (Diskussion | Beiträge) 21:00, 26. Jan. 2010 (CET)) Beantworten

habe Hivemind gelöscht. Links im Artikel können wir gemäß WP:Weblinks nicht machen. --Sebastian.Dietrich 23:37, 26. Jan. 2010 (CET) Beantworten