##entfällt: LE 13 | DI - Dependecy Injection

Question 1

Dependecy Injection

Answer 1

• Die Komponente die die Abhängigkeit benötigt wird als Dependant bezeichnet
• Hollywood-Prinzip: Dont call us, we call you
  
  • Framework welches die Programmkontrolle hat und registrierte Komponenten aufruft
  • Es geht lediglich um die Kommunikation, nicht um den Aufbau von Komponenten
• DI ist ein Entwurfsmuster
• Ziel ist die Abhängigkeiten von Komponenten zu minimieren und diese durch ein Framework oder sonstige Mechanismen aufzulösen.
• Benötigt A die Komponente B, so sollte A lediglich das Interface von B kennen, die konkrete Implementierung der Abhängigkeit wird durch das Framework oder andere Mechanismen geliefert. Die Abhängigkeit wird quasi „von außen injiziert” _
• Wissen der Komponentenabhängigkeiten soll externalisiert werden. Die Komponente soll also davon befreit werden, konkret zu wissen, mit welchen anderen Komponenten sie kommuniziert
• DI fördert Wartbarkeit, Testbarkeit und Änderbarkeit
  
  • Änderbarkeit/Wartbarkeit: Komponente A ist abhängig von B. Warum sollte sich A ändern, wenn in B Änderungen auftreten.
  • Änderbarkeit: lmplementierungen von Interfaces können sehr einfach ausgetauscht werden
  • Testbarkeit: Komponente A soll zu Testzwecken ausgetauscht werden und durch ein Mock ersetzt werden. Ohne Di müsste dafür der Code der Komponente geändert werden, die A als Abhängigkeit hat. Das sollte aber nicht sein müssen.
• lmplementierungen können leicht ausgetauscht werden, ohne das der eigentliche Quelltext geändert werden muss

Question 2

Möglichkeiten um Komponentenabhängigkeiten aufzulösen

Answer 2

Möglichkeiten um Komponentenabhängigkeiten aufzulösen

• Factories:
  
  • Nachteile:
    
    • Factory-Code immer selbst und für Ergänzungen neu schreiben
    • Entscheidung ob Singleton oder nicht? Kein Singleton hätte eine umständlichere Implementierung zur Folge
    • Factory-Code ist ggf nicht Threadsafe
    • Nested Hierarchien
• Abhängigkeit im Kostruktor übergeben
  
  • Ohne Übergabekomponente wird die Default-Abhängigkeit benutzt
  • Ansonsten von Hand neue Instanz erzeugen und dem Konstruktor übergeben
• Nachteile dieser beiden Varianten: _
  
  • Zusammenbau von Objektbäumen mit vielen Abhängigkeiten über mehrere Hierarchieebenen. Diese müsste der Entwickler selbst erzeugen und „zusammensetzen”. Kann wesentlich besser durch ein Dl-Framework getan werden. Der Anwender definiert also nur noch A nutztjetzt B und der Rest geschieht automatisch.
  • Gute DI-Frameworks bieten verschiedene Scopes an: Singleton, No-Scope, Session, Transaction, etc.

Question 3

Dependency Injection Typen

Answer 3

Question 4

Nachteile der Konstruktor-Injection

Answer 4

Nachteile der Konstruktor-Injection:

• Kann nur einmal aufgerufen werden
• Kann nicht anders benannt werden
• Bei vielen Feldern wird der Konstruktor sehr lang und viele Objekte müssen ggf in „method objects” umgewandelt werden. Hier wird eine Methode per Interface definiert, die vom Framework aufgerufen werden kann und alle Abhängigkeiten übergibt (Interface Injection)
• Wird dennoch von vielen Entwicklern bevorzugt, da es eine sauber notierte Variante darstellt.
• Falls zu viele Abhängigkeiten vorliegen stimmt ggf sowieso etwas mit dem Design nicht.

Question 5

Setter-injection

Answer 5

Setter-injection

• Wird aus den gegebenen Nachteilen häufiger genutzt als Konstruktor
• Hauptsächlich wenn weder die Setter selbst geschrieben werden müssen, noch die Abhängigkeiten einfach per Annotation übergeben werden kann
• Field injection
  
  • Abhängigkeit wird als Feld definiert und von außen durch Konstruktor oder Setter übergeben
  • Abhängigkeiten werden zb in XML gesetzt und aus einer Factory-Methode des Frameworks geholt

Question 6

Vorteile des DI-Ansatzes

Answer 6

Vorteile des DI-Ansatzes

• Einfaches Testen durch injizieren von Mocks
• Trennung von Code durch Einführung weiterer lndirektionsstufen gg
• Geringe Kohäsion möglich
• Einsparungen bei sich wiederholendem Code
• Wartbarkeit des Codes erhöht sich
• Änderungen am Code haben nicht mehr zur Folge das der Code bricht

Question 7

Nachteile des Di-Ansatzes

Answer 7

Nachteile des Di-Ansatzes

• in kleinen Projekten kann unnötiger Overhead entstehen
• Konfiguration eines Dl-Frameworks kann aufwendig sein
  
  • z.B. Pflegen einer XML-Datei mit vielen Einträgen, was wieder Fehler verursachen kann
• DI macht den Code eventuell komplizierter