Alles rund ums Software Development
Heute kommen wir zum Abschluß des Dependency Injection Themas. Nachdem 3 Konzepte vorgestellt wurde, gibt es heute 3 Frameworks, die diese Konzepte umsetzen. Die sind zum Teil ersetzbar, aber es geht hier auch darum Alternativen aufzuzeigen. Es schließt sich somit der Kreis und die Unklarheiten der Konzeptartikel werden aufgeklärt.
Eigentlich sollte ja der vierte Dependency Injection Teil erscheinen, aber da die Woche so kurz ist (heute ist ja in dem einen oder anderen Bundesland ein Feiertag) und ich noch ein anderes Thema hier habe, wird dieses einfach mal vorgezogen. Es geht heute um Jabber im Allgemeinen und um Google Talk im Speziellen.
Letzte Woche haben wir in der Dependency Injection Serie die Setter Injection gesehen. Und genau dieses Konzept wollen wir jetzt noch einen Schritt weiter treiben. Die heute vorgestellte Vorgehensweise entkoppelt die beiden Klassen dazu noch etwas mehr.
Letzte Woche gab es den ersten Teil der DI-Beitragsreihe. Es wurde das Konzept der Constructor Injection vorgestellt. Heute wollen wir einen kleinen Schritt weiter in Richtung DI-Container gehen. Dafür wird ein weiteres Konzept vorgestellt, dass eine Alternative zur Constructor Injection ist.
Das Grundkonzept der Inversion of Control wird aktuell sehr oft durch eine Dependency Injection Implementierung erfüllt. HIerbei wird zumeist auf DI-Container zurückgegriffen. Es ist aber vom Konzept nicht unbedingt notwendig und daher gibt es im Teil 1 der Artikelserie ein Beispiel für eine Art Dependency Injection zu nutzen ohne auf einen DI-Container zurück zugreifen.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
