Singleton Problem

das mag jetzt vielleicht ein bisschen provokant klingen, aber ich meine es nicht so, meine Frage ist ernst gemeint.

Ist Dependency Injection nicht eine furchtbar komplizierte Beschreibung einer einfachen Sache welche man auf ein pseudo akademisches Niveau erhoben und verkompliziert hat (damit manche Buchautoren einen Grund haben ihre Werke an den Mann zu bringen und darüber referieren können)?

Kann man das nicht einfach so zusammenfassen:
Ich will Code testen welcher in der Echtumgebung auf Daten zugreifen muss die zur Testzeit nicht zur Verfügung stehen und daher logischerweise im Test über einen anderen Mechanismus erzeugt und bereitgestellt werden müssen damit ich den Test auch ausführen kann.
Wie man das am besten macht hängt jeweils von den gegebenen Umständen ab, ein Rezept für alles kann es nicht geben.

ist DI etwas anderes oder geht DI über das hinaus?

sory darür das ich das in den Singleton Thread schreib, ich denke aber der hat sein Topic eh schon etwas gewechselt.

Eisflamme

ist DI etwas anderes oder geht DI über das hinaus?

Genau das wird doch seit einigen Seiten diskutiert. Ich schlage vor Du liest Dir das alles erstmal durch...

volkard

kurze_frage schrieb:

Ist Dependency Injection nicht eine furchtbar komplizierte Beschreibung einer einfachen Sache welche man auf ein pseudo akademisches Niveau erhoben und verkompliziert hat (damit manche Buchautoren einen Grund haben ihre Werke an den Mann zu bringen und darüber referieren können)?

Und eine furchtbar wichtig klingende Beschreibung einer vollkommen unwichtigen Sache.

Naja, das kann man so oder sorum sehen. Wir kommen hier aus einer ziemlich enterprisigen Denkrichtung -- dass der ganze Kram mit Assemblern etc. von Fowler als "lightweight" beschrieben wird, macht das recht deutlich.

Im Grunde geht es bei dependency injection mehr um ein Verwendungs- als ein Implementationsmuster. Du willst die konkreten Klassen der Datenmember deines Objekts nicht in dessen Klasse selbst bestimmen müssen, also lagerst du es aus, und anstatt das in einen service locator zu tun (der auch nur durch seine Verwendung prinzipiell etwas anderes als eine factory ist), aus dem sich der Konstruktor jener Klasse die konkreten Objekte holen kann, setzt du bei dependency injection einen Assembler/Injektor hin, der die konkreten Datenmember des Objektes vorher selbst baut und dem Konstruktor des Objekts übergibt (oder sie auf andere Weise in dieses Objekt schiebt).

In der Praxis wird das durch Dinge kompliziert, die in dieser Kerndefinition nicht vorkommen. Wenn du ein Dependency-Injection-Framework auspackst, bringt das gerne Dinge mit, die den ganzen Verwaltungsaufwand so gut wie möglich vor dem Client-Code verstecken. Ich nehme mal Google Guice als Beispiel: da wird mit Annotations rangeschrieben, welche Konstruktoren für Injection gedacht sind und welche Methoden eines Abhängigkeitsauflösungsmoduls (TODO: besseren Namen finden) Abhängigkeitsobjekte erstellen, und der Injektor, der vorher mit einem solchen Modul initialisiert wurde, sucht sich per Reflection raus, welche Methoden des Moduls er benutzen kann, schreibt diese völlig um, und sucht sich raus, welche Konstruktoren der Klasse, von der er ein Objekt bauen soll, er verwenden kann. Im Client-Code steht dann zur Erstellung der eigentlichen Objekte nur noch etwa

Foo bar = injector.getInstance(Foo.class);

Details hier: https://code.google.com/p/google-guice/wiki/Motivation

Um den Bogen zu Singletons zurückzuschlagen: Wo die Diskussion ursprünglich mal herkam, ist, dass das Rumreichen eines Objekts, auf das andere Objekte dann Referenzen zur Verwendung halten sollen (dies wurde als Alternative zu Singletons erwähnt und ist auch in der Tat besser) keine dependency injection ist. Ich halte es auch nicht für sinnvoll, den Begriff so weit aufweichen zu wollen, dass allein das halten eines Zeigers-auf-Basisklasse dependency injection darstellt, weil dann auch Strategy, Composite sowie ein halbes Dutzend anderer Design Patterns unter den Begriff fiele und std::unique_ptr ein Beispiel für DI wäre.

vielen Dank für die Erläuterung seldon