<\/p>\n
Dependency-Inversion-Prinzip (DIP)<\/h2>\n\u201eModule h\u00f6herer Ebenen sollten nicht von Modulen niedrigerer Ebenen abh\u00e4ngen.
\nBeide sollten von Abstraktionen abh\u00e4ngen.<\/p>\n
Abstraktionen sollten nicht von Details abh\u00e4ngen.
\nDetails sollten von Abstraktionen abh\u00e4ngen.\u201c<\/p>\n
— Dependency-Inversion-Prinzip (Quelle: Wikipedia<\/a>)<\/p><\/blockquote>\n <\/p>\n
Erl\u00e4uterung des Prinzips<\/h2>\n
![\"DIP_Abh\u00e4ngikeitKlassen\"](\"http:\/\/invidit.de\/blog\/wp-content\/uploads\/2015\/05\/DIP_Abh\u00e4ngikeitKlassen.png\")
<\/a>Annahme: wir haben zwei Klassen in unterschiedlichen Paketen bzw. Namensr\u00e4umen, von denen eine Klasse die andere Klasse kennt. Damit besteht zwischen den beiden Paketen eine Abh\u00e4ngigkeit. Ja und? Was ist das Problem? Mit einer starken Kopplung zwischen Paketen und generell zwischen Klassen nimmt die Austauschbarkeit ab. Nehmen wir als Beispiel einen CRUD-Service, der an eine bestimmte Implementierung einer Datenbankschicht gekoppelt ist. Was passiert, wenn die Datenbank gewechselt werden soll? Die Abh\u00e4ngigkeiten sind durch \u00c4nderung des Programmcodes aufzul\u00f6sen, bevor eine neue Implementierung der Datenbankschicht angebunden werden kann. Was kann ich machen, um die Kopplung besser – also lose – zu gestalten?<\/p>\n <\/p>\n
![\"DIP_Abh\u00e4ngikeitMitInterface\"](\"http:\/\/invidit.de\/blog\/wp-content\/uploads\/2015\/05\/DIP_Abh\u00e4ngikeitMitInterface.png\")
<\/a> Um Kopplungen durch Implementierungen auszul\u00f6sen, k\u00f6nnen Schnittstellen eingef\u00fchrt werden. Was f\u00fcr unser Beispiel dann wie links stehend aussehen k\u00f6nnte. Dabei zeigt das gr\u00fcne Rechteck eine Schnittstelle (Interface), welche von der orangefarbene Klasse verwendet und von der blauen Klasse implementiert wird. Befinden sich orangefarbene Klasse und Schnittstelle in einem Paket, kann das drunter liegende Paket ausgetauscht werden, ohne in dem Paket dar\u00fcber eine \u00c4nderung vornehmen zu m\u00fcssen. Das neue Paket bringt einfach eine neue Implementierung der Schnittstelle mit.<\/p>\nIn diesem Fall haben wir die Abh\u00e4ngigkeit umgedreht: bisher vom oberen Paket zum unteren, jetzt vom unteren Paket zum oberen.<\/p>\n
<\/p>\n
![\"DIP_CP\"](\"http:\/\/invidit.de\/blog\/wp-content\/uploads\/2015\/05\/DIP_CP.png\")
<\/a> Weiterhin k\u00f6nnen durch direkte Verwendung von Implementierungen, also Klassen, zirkul\u00e4re Abh\u00e4ngigkeiten entstehen, wie nebenstehende Grafik veranschaulicht. Diese Kreisabh\u00e4ngigkeiten kann der Compiler \u00fcblicherweise aufl\u00f6sen. Wenn allerdings ein Build-Server im Einsatz ist, kann dies bereits zum Problem f\u00fchren. Dadurch, dass sich ein verwendetes Paket \/ Klasse \u00e4ndert, muss das gerade betrachtete Paket \/ Klasse erneut erstellt werden, davon gibt es wieder eine Abh\u00e4ngigkeit, die erstellt werden muss – womit sich das System im Kreis dreht. Auch im Fall, dass die Implementierung angepasst werden muss, kann sich die \u00c4nderung durch alle Pakete \/ Klassen durchziehen. Wo fange ich an, wo h\u00f6re ich auf?<\/p>\n <\/p>\n
<\/p>\n
<\/p>\n
![\"DIP_CPUnterbrochen\"](\"http:\/\/invidit.de\/blog\/wp-content\/uploads\/2015\/05\/DIP_CPUnterbrochen.png\")
<\/a>Wie links gezeigt, lassen sich zirkul\u00e4re Abh\u00e4ngigkeiten auch durch das Einziehen von Schnittstellen aufbrechen. Der rote Pfeil im Bild deutet an, dass hier die Richtung der Abh\u00e4ngigkeit gedreht wurde. Damit ist die Kreisabh\u00e4ngigkeit unterbrochen.<\/p>\nGrunds\u00e4tzlich ist das DIP nicht mit dependecy injection – also dem injizieren von Abh\u00e4ngigkeiten zu verwechseln. Ein inversion of control (IoC) Framgework wie z.B. Spring \u00fcbernimmt dabei die Aufgabe, anhand der verwendeten Schnittstellen konkrete Implementierungen bereitzustellen. Grundvoraussetzung daf\u00fcr ist, dass die Abh\u00e4ngigkeiten durch Schnittstellen bereits aufgel\u00f6st wurden.<\/p>\n
Grunds\u00e4tzlich haben wir mindestens im Open Closed Principle<\/a> die lose Kopplung durch Schnittstellen besprochen.<\/p>\n <\/p>\n
Weiterhin erreichen wird mit dem DIP:<\/p>\n
\n- Unabh\u00e4ngigkeit zwischen Klassen und Modulen<\/li>\n
- Ver\u00e4nderbarkeit und Austauschbarkeit<\/li>\n
- Wiederverwendbarkeit<\/li>\n<\/ul>\n
<\/p>\n
Unsere Erfahrung mit dem DIP<\/h2>\n
In einigen unserer Projekte haben wir ein IoC Framework verwendet (z.B. Ninject<\/a>) und daher grunds\u00e4tzlich mit Schnittstellen gearbeitet. Aber auch ohne Framework hat es sich als vorteilhaft erweisen, anstelle gegen eine Klasse, besser gegen eine Schnittstelle zu programmieren. Die Flexibilit\u00e4t ist deutlich h\u00f6her. Zus\u00e4tzlich hat sicherlich jeder mit Erfahrung in Unit Tests h\u00e4ufig festgestellt, dass sich Code mit Schnittstelle leichter testen l\u00e4sst. Mocks und Stubs k\u00f6nnen einfacher eingef\u00fchrt, die zu testende Implementierung leichter isoliert werden.<\/p>\n![\"Battlez](\"http:\/\/invidit.de\/blog\/wp-content\/uploads\/2015\/05\/Battlez-Server-Architecture-250x300.png\")
<\/a><\/p>\n <\/p>\n
Im Projekt Battlez haben wir eine \u00fcbliche 3-Schichten Architektur verwendet (hier Netzwerk, Logik und UI, siehe Bild rechts) womit die verwendeten Bibliotheken f\u00fcr die Netzwerk-Kommunikation (wir nutzen LidgrenNetwork <\/a>in einem eigenen Wrapper) sehr leicht auszutauschen sind – gekoppelt ist diese \u00fcber nur zwei Schnittstellen.<\/p>\n
\u201eModule h\u00f6herer Ebenen sollten nicht von Modulen niedrigerer Ebenen abh\u00e4ngen.
\nBeide sollten von Abstraktionen abh\u00e4ngen.<\/p>\n
Abstraktionen sollten nicht von Details abh\u00e4ngen.
\nDetails sollten von Abstraktionen abh\u00e4ngen.\u201c<\/p>\n
— Dependency-Inversion-Prinzip (Quelle: Wikipedia<\/a>)<\/p><\/blockquote>\n <\/p>\n <\/p>\n In diesem Fall haben wir die Abh\u00e4ngigkeit umgedreht: bisher vom oberen Paket zum unteren, jetzt vom unteren Paket zum oberen.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Grunds\u00e4tzlich ist das DIP nicht mit dependecy injection – also dem injizieren von Abh\u00e4ngigkeiten zu verwechseln. Ein inversion of control (IoC) Framgework wie z.B. Spring \u00fcbernimmt dabei die Aufgabe, anhand der verwendeten Schnittstellen konkrete Implementierungen bereitzustellen. Grundvoraussetzung daf\u00fcr ist, dass die Abh\u00e4ngigkeiten durch Schnittstellen bereits aufgel\u00f6st wurden.<\/p>\n Grunds\u00e4tzlich haben wir mindestens im Open Closed Principle<\/a> die lose Kopplung durch Schnittstellen besprochen.<\/p>\n <\/p>\n Weiterhin erreichen wird mit dem DIP:<\/p>\n <\/p>\n In einigen unserer Projekte haben wir ein IoC Framework verwendet (z.B. Ninject<\/a>) und daher grunds\u00e4tzlich mit Schnittstellen gearbeitet. Aber auch ohne Framework hat es sich als vorteilhaft erweisen, anstelle gegen eine Klasse, besser gegen eine Schnittstelle zu programmieren. Die Flexibilit\u00e4t ist deutlich h\u00f6her. Zus\u00e4tzlich hat sicherlich jeder mit Erfahrung in Unit Tests h\u00e4ufig festgestellt, dass sich Code mit Schnittstelle leichter testen l\u00e4sst. Mocks und Stubs k\u00f6nnen einfacher eingef\u00fchrt, die zu testende Implementierung leichter isoliert werden.<\/p>\n <\/p>\n Im Projekt Battlez haben wir eine \u00fcbliche 3-Schichten Architektur verwendet (hier Netzwerk, Logik und UI, siehe Bild rechts) womit die verwendeten Bibliotheken f\u00fcr die Netzwerk-Kommunikation (wir nutzen LidgrenNetwork <\/a>in einem eigenen Wrapper) sehr leicht auszutauschen sind – gekoppelt ist diese \u00fcber nur zwei Schnittstellen.<\/p>\nErl\u00e4uterung des Prinzips<\/h2>\n
<\/a>Annahme: wir haben zwei Klassen in unterschiedlichen Paketen bzw. Namensr\u00e4umen, von denen eine Klasse die andere Klasse kennt. Damit besteht zwischen den beiden Paketen eine Abh\u00e4ngigkeit. Ja und? Was ist das Problem? Mit einer starken Kopplung zwischen Paketen und generell zwischen Klassen nimmt die Austauschbarkeit ab. Nehmen wir als Beispiel einen CRUD-Service, der an eine bestimmte Implementierung einer Datenbankschicht gekoppelt ist. Was passiert, wenn die Datenbank gewechselt werden soll? Die Abh\u00e4ngigkeiten sind durch \u00c4nderung des Programmcodes aufzul\u00f6sen, bevor eine neue Implementierung der Datenbankschicht angebunden werden kann. Was kann ich machen, um die Kopplung besser – also lose – zu gestalten?<\/p>\n<\/a> Um Kopplungen durch Implementierungen auszul\u00f6sen, k\u00f6nnen Schnittstellen eingef\u00fchrt werden. Was f\u00fcr unser Beispiel dann wie links stehend aussehen k\u00f6nnte. Dabei zeigt das gr\u00fcne Rechteck eine Schnittstelle (Interface), welche von der orangefarbene Klasse verwendet und von der blauen Klasse implementiert wird. Befinden sich orangefarbene Klasse und Schnittstelle in einem Paket, kann das drunter liegende Paket ausgetauscht werden, ohne in dem Paket dar\u00fcber eine \u00c4nderung vornehmen zu m\u00fcssen. Das neue Paket bringt einfach eine neue Implementierung der Schnittstelle mit.<\/p>\n<\/a> Weiterhin k\u00f6nnen durch direkte Verwendung von Implementierungen, also Klassen, zirkul\u00e4re Abh\u00e4ngigkeiten entstehen, wie nebenstehende Grafik veranschaulicht. Diese Kreisabh\u00e4ngigkeiten kann der Compiler \u00fcblicherweise aufl\u00f6sen. Wenn allerdings ein Build-Server im Einsatz ist, kann dies bereits zum Problem f\u00fchren. Dadurch, dass sich ein verwendetes Paket \/ Klasse \u00e4ndert, muss das gerade betrachtete Paket \/ Klasse erneut erstellt werden, davon gibt es wieder eine Abh\u00e4ngigkeit, die erstellt werden muss – womit sich das System im Kreis dreht. Auch im Fall, dass die Implementierung angepasst werden muss, kann sich die \u00c4nderung durch alle Pakete \/ Klassen durchziehen. Wo fange ich an, wo h\u00f6re ich auf?<\/p>\n<\/a>Wie links gezeigt, lassen sich zirkul\u00e4re Abh\u00e4ngigkeiten auch durch das Einziehen von Schnittstellen aufbrechen. Der rote Pfeil im Bild deutet an, dass hier die Richtung der Abh\u00e4ngigkeit gedreht wurde. Damit ist die Kreisabh\u00e4ngigkeit unterbrochen.<\/p>\n\n
Unsere Erfahrung mit dem DIP<\/h2>\n
<\/a><\/p>\n