3. Inversion of Control IoC

Wenden wir uns nun dem Konzept der Inversion of Control (IoC) zu, das von Spring zur Konfiguration von Anwendungen verwendet wird. Um dieses Konzept zu veranschaulichen, kehren wir zur Architektur unserer vorherigen Testanwendung zurück:

Um auf die Daten von SGBD zuzugreifen, muss die Testklasse die Dienste eines Objekts nutzen, das die Schnittstelle [IArticlesDao] implementiert, beispielsweise ein Objekt vom Typ [ArticlesDaoPlainODBC]. Wir haben zwei mögliche Lösungen zur Instanziierung eines solchen Objekts untersucht:

• Bei der ersten Lösung forderte die Testklasse selbst die Instanziierung eines Objekts vom Typ [ArticlesDaoPlainODBC] an:

    <TestFixture()> _
    Public Class NunitTestArticlesDaoPlainOdbc

         ' das zu testende Objekt
        Private articlesDao As IArticlesDao

        <SetUp()> _
        Public Sub init()
             ' Es wird eine Instanz des zu testenden Objekts erstellt
            articlesDao = New ArticlesDaoPlainODBC("odbc-firebird-articles", "SYSDBA", "masterkey")
        End Sub
...
    End Class

Im Code besteht eine feste Abhängigkeit vom Klassennamen. Sollte sich die Klasse, die die Schnittstelle [IArticlesDao] implementiert, ändern, müsste der Code der Methode [init] angepasst werden. Es bestehen folgende Beziehungen zwischen den Objekten:

Die Klasse [NunitTestArticlesDaoPlainOdbc] übernimmt selbst die Initiative zur Erstellung des Objekts [ArticlesDaoPlainODBC], das sie benötigt. Um auf den Begriff „Kontrollumkehr“ zurückzukommen: Man könnte sagen, dass sie die „Kontrolle“ darüber hat, das Objekt zu erstellen, das sie benötigt.

• Die zweite Lösung geht anders vor. Die Testklasse sieht nun wie folgt aus:

    <TestFixture()> _
    Public Class NunitSpringTestArticlesDaoPlainOdbc

         ' das zu testende Objekt
        Private articlesDao As IArticlesDao

        <SetUp()> _
        Public Sub init()
       ' eine Instanz des Spring-Objektgenerators wird abgerufen
            Dim factory As XmlObjectFactory = New XmlObjectFactory(New FileStream("spring-config-plainodbc.xml", FileMode.Open))
       ' Die Instanziierung des DAO-Objekts „articles“ wird angefordert
            articlesDao = CType(factory.GetObject("articlesdao"), IArticlesDao)
        End Sub
    ...
    End Class

Dieser Mechanismus lässt sich wie folgt schematisch darstellen:

Hier ergreift die Testklasse nicht selbst die Initiative, um die Erstellung eines Objekts [ArticlesDaoPlainODBC] anzufordern. Sie begnügt sich damit, von Spring eine Referenz auf ein solches Objekt anzufordern. Wenn das Objekt existiert, gibt Spring eine Referenz darauf zurück. Wenn es nicht existiert, erstellt Spring es. Die Testklasse hat die Kontrolle über die Erstellung des Objekts [ArticlesDaoPlainODBC] verloren. Sie fordert lediglich eine Referenz auf dieses Objekt an. Diese Anforderung zwingt Spring in diesem Fall dazu, das Objekt zu erstellen. Man könnte sich jedoch in einem anderen Kontext vorstellen, dass das angeforderte Objekt bereits auf Anfrage der Anwendung erstellt wurde. Spring erstellt das Objekt dann nicht erneut, sondern gibt eine Referenz auf das bereits vorhandene Objekt (Singleton) zurück. Der Begriff „Inversion of Control“ (IoC) bedeutet hier:

• dass die Anwendung niemals selbst die Initiative ergreift, die von ihr benötigten Singletons zu erstellen. Sie fordert lediglich Referenzen darauf an.
• Spring trifft die Entscheidung, ein Singleton zu erstellen, wenn zum ersten Mal eine Referenz darauf angefordert wird