SlideShare ist ein Scribd-Unternehmen logo
Inversion of Control
Oder: „Wie man Flexibilität durch Verlagerung
von Kontrolle erreichen kann“
Daniel Volk
24.01.2010
Folie 2/27
Agenda
  Dependency Inversion
  Komplexitätsbeherrschung
  Flexibilität und Stabilität
  Inversion of Control
  Verlagerung des Kontrollflusses
  Verlagerung von Objekterstellung und –konfig.
  Dependency Injection
  Allgemeines
  Der Spring IoC-Container
Daniel Volk
24.01.2010
Folie 3/27
Dependency Inversion
  Ausgangspunkt
  Softwareentwicklung zeichnet sich durch eine
inhärente Komplexität der Materie und eine
hohe Änderungsfrequenz aus
  Komplexitätsbeherrschung
  Der genannten Komplexität wird man u.a.
durch Dekomposition des Problems Herr
  In der Folge entsteht eine Vielzahl von Modulen
auf unterschiedlichen Ebenen (z.B. Klassen,
Komponenten, Dienste) mit verschiedenen
Beziehungen untereinander
Daniel Volk
24.01.2010
Folie 4/27
Dependency Inversion
  Entwurfsprinzipien
  Um die Zerlegung des Problems in geordneten
Bahnen ablaufen zu lassen, finden mehrere (teils
überlappende) Entwurfsprinzipien Anwendung:
  Single Responsibility Principle
  Jedes Modul soll genau eine Verantwortung (für eine
Aufgabe) übernehmen
Daniel Volk
24.01.2010
Folie 5/27
Dependency Inversion
  Entwurfsprinzipien
  Separation of Concerns
  Eine Aufgabe soll nicht über mehrere Module verstreut
implementiert sein (Repräsentation durch ein Modul)
  Don‘t repeat yourself
  Gleiche Funktionalität innerhalb eines Systems sollte
auch nur einmal umgesetzt werden
Aber: Crosscutting Concerns!
Daniel Volk
24.01.2010
Folie 6/27
Dependency Inversion
  Ausgangspunkt
  Ergebnis der vorherigen Dekomposition ist ein
Modulgeflecht mit vielen Abhängigkeiten
welches anfällig für Änderungen ist
  Stabilität und Flexibilität
  Eine Strategie zur Behebung des Problems ist die
Verminderung des Abhängigkeitsgrades, eine
andere der explizite Entwurf für Erweiterbarkeit
  Erreichen kann man dies durch Reorganisation
der Module, Abstraktion und Indirektion
Daniel Volk
24.01.2010
Folie 7/27
Dependency Inversion
  Entwurfsprinzipien
  Information Hiding Principle
  Nur die zur Nutzung notwendige Information eines
Moduls soll nach außen sichtbar sein
  High Cohesion/ Loose Coupling
  Der Grad der Abhängigkeit sollte zwischen Teilen eines
Moduls hoch, zwischen Modulen selbst aber niedrig sein
z.B. per Facade-Pattern!
Daniel Volk
24.01.2010
Folie 8/27
Dependency Inversion
  Einschub
  Facade Pattern
  Intention: Multiple Zugriffspunkte innerhalb eines
Moduls werden durch eine einheitliche Schnittstelle
ersetzt (nicht notwendigerweise ein Java-Interface!)
Sichtbarkeiten der Sub-Module können
jetzt eingeschränkt werden!
Daniel Volk
24.01.2010
Folie 9/27
Dependency Inversion
  Entwurfsprinzipien
  Dependency Inversion Principle
  High-level Module sollen nicht von Low-Level Modulen
abhängen; beide sollen von Abstraktionen abhängen
  Abstraktionen sollen nicht von Details abhängen; Details
sollen von Abstraktionen abhängen (Inversion)
  Begründung (klassischer Top-Down-Entwurf)
Fortpflanzung von Änderungen
Richtung der Abhängigkeit
Und nun soll die Software
auf einem Mac laufen …
Daniel Volk
24.01.2010
Folie 10/27
Dependency Inversion
  Entwurfsprinzipien
  Dependency Inversion Principle
  Ein anderer Ansatz (Programming to Interfaces)
Inkompatible Schnittstellen lassen sich
mit Hilfe des Adapter-Pattern verbinden!
Daniel Volk
24.01.2010
Folie 11/27
Dependency Inversion
  Einschub
  Adapter Pattern
  Intention: Schaffung einer Vermittlungsinstanz
zwischen inkompatiblen Schnittstellendefinitionen
  Alternativen: Klassen-/ Objektadapter
Abstraktion aus High-Level Sicht Abstraktion aus Low-Level Sicht
Daniel Volk
24.01.2010
Folie 12/27
Agenda
  Dependency Inversion
  Komplexitätsbeherrschung
  Flexibilität und Stabilität
  Inversion of Control
  Verlagerung des Kontrollflusses
  Verlagerung von Objekterstellung und –konfig.
  Dependency Injection
  Allgemeine Erläuterungen
  Der Spring IoC-Container
Daniel Volk
24.01.2010
Folie 13/27
Inversion of Control
  Ausgangspunkt
  Module hängen nun von Abstraktionen ab;
High-Level M. durch Nutzung direkt, Low-Level M.
durch Konkretisierung invertiert, aber…
Darstellungs-
Framework
Nicht nur Funktionalität, auch
Abläufe sind wiederverwendbar
?
Daniel Volk
24.01.2010
Folie 14/27
Inversion of Control
  Arten der Inversion of Control
  Verlagerung des Kontrollflusses
  Ein spezifisches Modul wird von einem mehrfach
verwendbaren Modul (Framework) aufgerufen
(Hollywood Principle: „Don‘t call us, we‘ll call you“)
Framework
Kontrollfluss
Spezifischer
Anteil
Abstraktion
Spezifischer
Anteil
Abstraktion
Spezifischer
Anteil
Abstraktion
Nutzung von Template-
bzw. Observer-Pattern
Oder noch flexibler:
per Annotationen!
Daniel Volk
24.01.2010
Folie 15/27
Inversion of Control
  Einschub
  Template Pattern
  Intention: Definition eines Grobablaufs der Teile seiner
Implementierung an Sub-Module delegiert
  Observer Pattern
  Intention: Automatische Konsistenzwahrung zwischen
lose gekoppelten Modulen
„Hook“-Methods
Daniel Volk
24.01.2010
Folie 16/27
Inversion of Control
  Ausgangspunkt
  Module hängen nun von Abstraktionen ab;
High-Level M. durch Nutzung direkt, Low-Level M.
durch Konkretisierung invertiert, aber…
Wie kann man die
Module flexibel erstellen
und verknüpfen
(z.B. zu Testzwecken?)
Daniel Volk
24.01.2010
Folie 17/27
Inversion of Control
  Einschub
  Testbarkeit als Motivation
  Einfaches Beispiel: Modul B soll mit Hilfe eines
funktionalen Komponententests überprüft werden
  Und das alles möglichst ohne jedes Mal das komplette
Programm umschreiben zu müssen…
<Testling>
Modul B
Modul C
Modul D
Modul A
Testreiber nimmt
Rolle des Moduls ein Muss durch MockUp
ersetzt werden, da
noch nicht getestet
Konfiguration muss
wg. Zugriffs auf Test-
DB geändert werden
Soll einen Zustand einnehmen, der nicht
dem originären Startzustand entspricht (soll
aber auch nicht instrumentiert werden)
Daniel Volk
24.01.2010
Folie 18/27
Inversion of Control
  Arten der Inversion of Control
  Verlagerung von Objekterstellung und –konfig.
  Dependency LookUp
  Das nutzende Quellmodul erfragt bei einer externen
Stelle das dort zuvor registrierte Zielmodul bzw. ein
Modul, welches mit dessen Erstellung beauftragt ist
  Das Szenario wird typischerweise mit einer Kombination
des Service Locator und des Static (bei Einzelobjekten)
bzw. des Abstract Factory Pattern (bei Verbünden
von Objekten) umgesetzt
Daniel Volk
24.01.2010
Folie 19/27
Inversion of Control
  Einschub
  Service Locator Pattern
  Intention: Eine externe Registratur für Objekte
  Abstract Factory Pattern
  Intention: Eine Schnittstelle zur Erstellung von
Objektfamilien ohne Kenntnis derer konkreten Klassen
( )
ServiceLocator
liefert Factory
Daniel Volk
24.01.2010
Folie 20/27
Agenda
  Dependency Inversion
  Komplexitätsbeherrschung
  Flexibilität und Stabilität
  Inversion of Control
  Verlagerung des Kontrollflusses
  Verlagerung von Objekterstellung und –konfig.
  Dependency Injection
  Allgemeine Erläuterungen
  Der Spring IoC-Container
Daniel Volk
24.01.2010
Folie 21/27
Dependency Injection
  Arten der Inversion of Control
  Verlagerung von Objekterstellung und –konfig.
  Dependency Injection (allgemein)
  Ein externes „Assembler“-Objekt übernimmt die
Erstellung und Zuweisung von Objekten und
Einstellungen
<<interface>>
Zielmodul
Assembler Zielmodul
Quellmodul
<<uses>>
<<creates>>
<<implements>><<injects>>
Daniel Volk
24.01.2010
Folie 22/27
Dependency Injection
  Arten der Inversion of Control
  Verlagerung von Objekterstellung und –konfig.
  Dependency Injection (Spring)
  Der umgebende Spring IoC Container übernimmt die
Verantwortung für den Lebenszyklus der Module
  Dieser „injiziert“ bei Erstellung die in externen
Konfigurationen definierten Objekte und Einstellungen
  Umsetzung per
  Constructor Injection
  Setter Injection
Daniel Volk
24.01.2010
Folie 23/27
Dependency Injection
  Ein kleines Beispiel mit Spring
  Das Interface für die Zielmodule
  Die potentiellen Zielmodule
public interface IMsgProducer {
public String getMessage();
}
public class ChattyMsgProducer implements IMsgProducer{
public String getMessage() {
return "Hello, I'm your message producer and I would like to...";
}
}
public class SleepyMsgProducer implements IMsgProducer {
public String getMessage() {
return("zzzZZZzzz");
}
}
Daniel Volk
24.01.2010
Folie 24/27
Dependency Injection
  Ein kleines Beispiel mit Spring
  Das Quellmodul
public class MsgConsumer {
private int repetitions;
private IMsgProducer msgProducer;
public void setRepetitions(int repetitions) {
this.repetitions = repetitions;
}
public void setMsgProducer(IMsgProducer msgProducer) {
this.msgProducer = msgProducer;
}
public void startConsuming() {
for (int i = 0; i < repetitions; i++)
System.out.println("MSG: " + msgProducer.getMessage());
}
}
Die Properties
der Bean
Die Setter-
Schnittstelle
Daniel Volk
24.01.2010
Folie 25/27
Dependency Injection
  Ein kleines Beispiel mit Spring
  Die Konfigurationsdatei
  Der Einsprungpunkt
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="…" xmlns:xsi="…" xsi:schemaLocation="…">
<bean id="msgConsumer" class="temp.MsgConsumer">
<property name="repetitions" value="3"/>
<property name="msgProducer" ref="chattyMsgProducer"/>
</bean>
<bean id="chattyMsgProducer" class="temp.ChattyMsgProducer"/>
</beans>
public static void main(String[] args) {
Resource resource = new ClassPathResource("./META-INF/chatty.xml");
BeanFactory factory = new XmlBeanFactory(resource);
((MsgConsumer) factory.getBean("msgConsumer")).startConsuming();
}
Das gewählte
Zielmodul
Zuweisung/
Referenzierung
Oder
ApplicationContext
Daniel Volk
24.01.2010
Folie 26/27
Dependency Injection
  Weitere Möglichkeiten der BeanFactory
  Dependencies
  Collections
  Autowiring
  Method Injection
  Bean Scopes
  Bean Lifecycle
  Initialization
  Destruction
  Awareness
  Bean Definition
  Inheritance
Daniel Volk
24.01.2010
Folie 27/27
Literatur & Links
  Gamma, Erich, Helm, Richard, Johnson, Ralph, Vlissides, John, 2001. Design
Pattern – Elements of Reusable Object-Oriented Software. Addison Wesley, IN,
USA.
  Lahres, Bernhard, Rayman, Gregor, 2009. Praxisbuch Objekt-Orientierung. 2.
Auflage, Galileo Press, Bonn.
  Vogel, Oliver et al., 2005. Software Architektur: Grundlagen – Konzepte – Praxis.
Elsevier GmbH, München.
  Alur, Deepak, Crupi, John, Malks, Dan, 2001. Core J2EE Patterns: Best Practices
and Design Strategies. 2. Auflage, Prentice Hall, NJ, USA.
  Martin, Robert C., 1996. The Dependency Inversion Principle. C++ Report, Vol.
8. URI: http://www.objectmentor.com/resources/articles/dip.pdf
  Fowler, Martin, 2004. Inversion of Control Containers and the Dependency
Injection pattern. URI: http://martinfowler.com/articles/injection.html
  Johnson, Rod et al., 2009. The Spring Framework – Reference Documentation.
URI: http://www.springsource.org/documentation

Weitere ähnliche Inhalte

Mehr von Daniel Volk

Digitale Produkttechnologien
Digitale ProdukttechnologienDigitale Produkttechnologien
Digitale Produkttechnologien
Daniel Volk
 
Evaluating Processing as a Platform for Game Prototyping
Evaluating Processing as a Platform for Game PrototypingEvaluating Processing as a Platform for Game Prototyping
Evaluating Processing as a Platform for Game Prototyping
Daniel Volk
 
Strategy Games - Introduction
Strategy Games - IntroductionStrategy Games - Introduction
Strategy Games - Introduction
Daniel Volk
 
Eine Einführung in das Risikomanagement
Eine Einführung in das RisikomanagementEine Einführung in das Risikomanagement
Eine Einführung in das Risikomanagement
Daniel Volk
 
Open Games Workshop - Hybride Spiele / Augmented Reality
Open Games Workshop - Hybride Spiele / Augmented RealityOpen Games Workshop - Hybride Spiele / Augmented Reality
Open Games Workshop - Hybride Spiele / Augmented Reality
Daniel Volk
 
Open Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Open Games Workshop - Spielemarkt, Spieleindustrie, SpieleentwicklungOpen Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Open Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Daniel Volk
 
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Daniel Volk
 
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Daniel Volk
 
Die Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Die Rolle eines modernen Publishers am Beispiel der Ravensburger DigitalDie Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Die Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Daniel Volk
 
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Daniel Volk
 
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Daniel Volk
 
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Daniel Volk
 

Mehr von Daniel Volk (12)

Digitale Produkttechnologien
Digitale ProdukttechnologienDigitale Produkttechnologien
Digitale Produkttechnologien
 
Evaluating Processing as a Platform for Game Prototyping
Evaluating Processing as a Platform for Game PrototypingEvaluating Processing as a Platform for Game Prototyping
Evaluating Processing as a Platform for Game Prototyping
 
Strategy Games - Introduction
Strategy Games - IntroductionStrategy Games - Introduction
Strategy Games - Introduction
 
Eine Einführung in das Risikomanagement
Eine Einführung in das RisikomanagementEine Einführung in das Risikomanagement
Eine Einführung in das Risikomanagement
 
Open Games Workshop - Hybride Spiele / Augmented Reality
Open Games Workshop - Hybride Spiele / Augmented RealityOpen Games Workshop - Hybride Spiele / Augmented Reality
Open Games Workshop - Hybride Spiele / Augmented Reality
 
Open Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Open Games Workshop - Spielemarkt, Spieleindustrie, SpieleentwicklungOpen Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Open Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
 
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
 
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
 
Die Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Die Rolle eines modernen Publishers am Beispiel der Ravensburger DigitalDie Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Die Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
 
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
 
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
 
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
 

Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kontrolle erreichen kann"

  • 1. Inversion of Control Oder: „Wie man Flexibilität durch Verlagerung von Kontrolle erreichen kann“
  • 2. Daniel Volk 24.01.2010 Folie 2/27 Agenda   Dependency Inversion   Komplexitätsbeherrschung   Flexibilität und Stabilität   Inversion of Control   Verlagerung des Kontrollflusses   Verlagerung von Objekterstellung und –konfig.   Dependency Injection   Allgemeines   Der Spring IoC-Container
  • 3. Daniel Volk 24.01.2010 Folie 3/27 Dependency Inversion   Ausgangspunkt   Softwareentwicklung zeichnet sich durch eine inhärente Komplexität der Materie und eine hohe Änderungsfrequenz aus   Komplexitätsbeherrschung   Der genannten Komplexität wird man u.a. durch Dekomposition des Problems Herr   In der Folge entsteht eine Vielzahl von Modulen auf unterschiedlichen Ebenen (z.B. Klassen, Komponenten, Dienste) mit verschiedenen Beziehungen untereinander
  • 4. Daniel Volk 24.01.2010 Folie 4/27 Dependency Inversion   Entwurfsprinzipien   Um die Zerlegung des Problems in geordneten Bahnen ablaufen zu lassen, finden mehrere (teils überlappende) Entwurfsprinzipien Anwendung:   Single Responsibility Principle   Jedes Modul soll genau eine Verantwortung (für eine Aufgabe) übernehmen
  • 5. Daniel Volk 24.01.2010 Folie 5/27 Dependency Inversion   Entwurfsprinzipien   Separation of Concerns   Eine Aufgabe soll nicht über mehrere Module verstreut implementiert sein (Repräsentation durch ein Modul)   Don‘t repeat yourself   Gleiche Funktionalität innerhalb eines Systems sollte auch nur einmal umgesetzt werden Aber: Crosscutting Concerns!
  • 6. Daniel Volk 24.01.2010 Folie 6/27 Dependency Inversion   Ausgangspunkt   Ergebnis der vorherigen Dekomposition ist ein Modulgeflecht mit vielen Abhängigkeiten welches anfällig für Änderungen ist   Stabilität und Flexibilität   Eine Strategie zur Behebung des Problems ist die Verminderung des Abhängigkeitsgrades, eine andere der explizite Entwurf für Erweiterbarkeit   Erreichen kann man dies durch Reorganisation der Module, Abstraktion und Indirektion
  • 7. Daniel Volk 24.01.2010 Folie 7/27 Dependency Inversion   Entwurfsprinzipien   Information Hiding Principle   Nur die zur Nutzung notwendige Information eines Moduls soll nach außen sichtbar sein   High Cohesion/ Loose Coupling   Der Grad der Abhängigkeit sollte zwischen Teilen eines Moduls hoch, zwischen Modulen selbst aber niedrig sein z.B. per Facade-Pattern!
  • 8. Daniel Volk 24.01.2010 Folie 8/27 Dependency Inversion   Einschub   Facade Pattern   Intention: Multiple Zugriffspunkte innerhalb eines Moduls werden durch eine einheitliche Schnittstelle ersetzt (nicht notwendigerweise ein Java-Interface!) Sichtbarkeiten der Sub-Module können jetzt eingeschränkt werden!
  • 9. Daniel Volk 24.01.2010 Folie 9/27 Dependency Inversion   Entwurfsprinzipien   Dependency Inversion Principle   High-level Module sollen nicht von Low-Level Modulen abhängen; beide sollen von Abstraktionen abhängen   Abstraktionen sollen nicht von Details abhängen; Details sollen von Abstraktionen abhängen (Inversion)   Begründung (klassischer Top-Down-Entwurf) Fortpflanzung von Änderungen Richtung der Abhängigkeit Und nun soll die Software auf einem Mac laufen …
  • 10. Daniel Volk 24.01.2010 Folie 10/27 Dependency Inversion   Entwurfsprinzipien   Dependency Inversion Principle   Ein anderer Ansatz (Programming to Interfaces) Inkompatible Schnittstellen lassen sich mit Hilfe des Adapter-Pattern verbinden!
  • 11. Daniel Volk 24.01.2010 Folie 11/27 Dependency Inversion   Einschub   Adapter Pattern   Intention: Schaffung einer Vermittlungsinstanz zwischen inkompatiblen Schnittstellendefinitionen   Alternativen: Klassen-/ Objektadapter Abstraktion aus High-Level Sicht Abstraktion aus Low-Level Sicht
  • 12. Daniel Volk 24.01.2010 Folie 12/27 Agenda   Dependency Inversion   Komplexitätsbeherrschung   Flexibilität und Stabilität   Inversion of Control   Verlagerung des Kontrollflusses   Verlagerung von Objekterstellung und –konfig.   Dependency Injection   Allgemeine Erläuterungen   Der Spring IoC-Container
  • 13. Daniel Volk 24.01.2010 Folie 13/27 Inversion of Control   Ausgangspunkt   Module hängen nun von Abstraktionen ab; High-Level M. durch Nutzung direkt, Low-Level M. durch Konkretisierung invertiert, aber… Darstellungs- Framework Nicht nur Funktionalität, auch Abläufe sind wiederverwendbar ?
  • 14. Daniel Volk 24.01.2010 Folie 14/27 Inversion of Control   Arten der Inversion of Control   Verlagerung des Kontrollflusses   Ein spezifisches Modul wird von einem mehrfach verwendbaren Modul (Framework) aufgerufen (Hollywood Principle: „Don‘t call us, we‘ll call you“) Framework Kontrollfluss Spezifischer Anteil Abstraktion Spezifischer Anteil Abstraktion Spezifischer Anteil Abstraktion Nutzung von Template- bzw. Observer-Pattern Oder noch flexibler: per Annotationen!
  • 15. Daniel Volk 24.01.2010 Folie 15/27 Inversion of Control   Einschub   Template Pattern   Intention: Definition eines Grobablaufs der Teile seiner Implementierung an Sub-Module delegiert   Observer Pattern   Intention: Automatische Konsistenzwahrung zwischen lose gekoppelten Modulen „Hook“-Methods
  • 16. Daniel Volk 24.01.2010 Folie 16/27 Inversion of Control   Ausgangspunkt   Module hängen nun von Abstraktionen ab; High-Level M. durch Nutzung direkt, Low-Level M. durch Konkretisierung invertiert, aber… Wie kann man die Module flexibel erstellen und verknüpfen (z.B. zu Testzwecken?)
  • 17. Daniel Volk 24.01.2010 Folie 17/27 Inversion of Control   Einschub   Testbarkeit als Motivation   Einfaches Beispiel: Modul B soll mit Hilfe eines funktionalen Komponententests überprüft werden   Und das alles möglichst ohne jedes Mal das komplette Programm umschreiben zu müssen… <Testling> Modul B Modul C Modul D Modul A Testreiber nimmt Rolle des Moduls ein Muss durch MockUp ersetzt werden, da noch nicht getestet Konfiguration muss wg. Zugriffs auf Test- DB geändert werden Soll einen Zustand einnehmen, der nicht dem originären Startzustand entspricht (soll aber auch nicht instrumentiert werden)
  • 18. Daniel Volk 24.01.2010 Folie 18/27 Inversion of Control   Arten der Inversion of Control   Verlagerung von Objekterstellung und –konfig.   Dependency LookUp   Das nutzende Quellmodul erfragt bei einer externen Stelle das dort zuvor registrierte Zielmodul bzw. ein Modul, welches mit dessen Erstellung beauftragt ist   Das Szenario wird typischerweise mit einer Kombination des Service Locator und des Static (bei Einzelobjekten) bzw. des Abstract Factory Pattern (bei Verbünden von Objekten) umgesetzt
  • 19. Daniel Volk 24.01.2010 Folie 19/27 Inversion of Control   Einschub   Service Locator Pattern   Intention: Eine externe Registratur für Objekte   Abstract Factory Pattern   Intention: Eine Schnittstelle zur Erstellung von Objektfamilien ohne Kenntnis derer konkreten Klassen ( ) ServiceLocator liefert Factory
  • 20. Daniel Volk 24.01.2010 Folie 20/27 Agenda   Dependency Inversion   Komplexitätsbeherrschung   Flexibilität und Stabilität   Inversion of Control   Verlagerung des Kontrollflusses   Verlagerung von Objekterstellung und –konfig.   Dependency Injection   Allgemeine Erläuterungen   Der Spring IoC-Container
  • 21. Daniel Volk 24.01.2010 Folie 21/27 Dependency Injection   Arten der Inversion of Control   Verlagerung von Objekterstellung und –konfig.   Dependency Injection (allgemein)   Ein externes „Assembler“-Objekt übernimmt die Erstellung und Zuweisung von Objekten und Einstellungen <<interface>> Zielmodul Assembler Zielmodul Quellmodul <<uses>> <<creates>> <<implements>><<injects>>
  • 22. Daniel Volk 24.01.2010 Folie 22/27 Dependency Injection   Arten der Inversion of Control   Verlagerung von Objekterstellung und –konfig.   Dependency Injection (Spring)   Der umgebende Spring IoC Container übernimmt die Verantwortung für den Lebenszyklus der Module   Dieser „injiziert“ bei Erstellung die in externen Konfigurationen definierten Objekte und Einstellungen   Umsetzung per   Constructor Injection   Setter Injection
  • 23. Daniel Volk 24.01.2010 Folie 23/27 Dependency Injection   Ein kleines Beispiel mit Spring   Das Interface für die Zielmodule   Die potentiellen Zielmodule public interface IMsgProducer { public String getMessage(); } public class ChattyMsgProducer implements IMsgProducer{ public String getMessage() { return "Hello, I'm your message producer and I would like to..."; } } public class SleepyMsgProducer implements IMsgProducer { public String getMessage() { return("zzzZZZzzz"); } }
  • 24. Daniel Volk 24.01.2010 Folie 24/27 Dependency Injection   Ein kleines Beispiel mit Spring   Das Quellmodul public class MsgConsumer { private int repetitions; private IMsgProducer msgProducer; public void setRepetitions(int repetitions) { this.repetitions = repetitions; } public void setMsgProducer(IMsgProducer msgProducer) { this.msgProducer = msgProducer; } public void startConsuming() { for (int i = 0; i < repetitions; i++) System.out.println("MSG: " + msgProducer.getMessage()); } } Die Properties der Bean Die Setter- Schnittstelle
  • 25. Daniel Volk 24.01.2010 Folie 25/27 Dependency Injection   Ein kleines Beispiel mit Spring   Die Konfigurationsdatei   Der Einsprungpunkt <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="…" xmlns:xsi="…" xsi:schemaLocation="…"> <bean id="msgConsumer" class="temp.MsgConsumer"> <property name="repetitions" value="3"/> <property name="msgProducer" ref="chattyMsgProducer"/> </bean> <bean id="chattyMsgProducer" class="temp.ChattyMsgProducer"/> </beans> public static void main(String[] args) { Resource resource = new ClassPathResource("./META-INF/chatty.xml"); BeanFactory factory = new XmlBeanFactory(resource); ((MsgConsumer) factory.getBean("msgConsumer")).startConsuming(); } Das gewählte Zielmodul Zuweisung/ Referenzierung Oder ApplicationContext
  • 26. Daniel Volk 24.01.2010 Folie 26/27 Dependency Injection   Weitere Möglichkeiten der BeanFactory   Dependencies   Collections   Autowiring   Method Injection   Bean Scopes   Bean Lifecycle   Initialization   Destruction   Awareness   Bean Definition   Inheritance
  • 27. Daniel Volk 24.01.2010 Folie 27/27 Literatur & Links   Gamma, Erich, Helm, Richard, Johnson, Ralph, Vlissides, John, 2001. Design Pattern – Elements of Reusable Object-Oriented Software. Addison Wesley, IN, USA.   Lahres, Bernhard, Rayman, Gregor, 2009. Praxisbuch Objekt-Orientierung. 2. Auflage, Galileo Press, Bonn.   Vogel, Oliver et al., 2005. Software Architektur: Grundlagen – Konzepte – Praxis. Elsevier GmbH, München.   Alur, Deepak, Crupi, John, Malks, Dan, 2001. Core J2EE Patterns: Best Practices and Design Strategies. 2. Auflage, Prentice Hall, NJ, USA.   Martin, Robert C., 1996. The Dependency Inversion Principle. C++ Report, Vol. 8. URI: http://www.objectmentor.com/resources/articles/dip.pdf   Fowler, Martin, 2004. Inversion of Control Containers and the Dependency Injection pattern. URI: http://martinfowler.com/articles/injection.html   Johnson, Rod et al., 2009. The Spring Framework – Reference Documentation. URI: http://www.springsource.org/documentation