© OpturaDesign/Shutterstock.com
Windows Developer
Teil 1: Dependency Injection in Aktion

Clean Code durch Design Patterns

Vielfach gehört, recherchiert, gelesen und dennoch nicht verstanden: Dependency Injection. Ein mysteriöses Design Pattern mit sehr vielen Benefits, wie wir sehen werden. Nach diesem Artikel verstehen Sie Dependency Injection nicht nur, Sie werden von der Magie überwältigt sein und sie nicht mehr hergeben wollen.

Oğuzhan Açıkgöz


ArtikelserieTeil 1: Dependency Injection in AktionTeil 2: Repository-Pattern-Kapselung der DatenschichtTeil 3: Unit-of-Work-Pattern – schlanke Transaktionen an die Datenbank

Über Softwarearchitektur lässt sich meines Erachtens kein allgemeingültiger Konsens finden, nicht einmal in den kleinsten Entwicklergruppen und den flachsten Hierarchien. Die Begründung dafür ist einfach: Die einen sind sehr zielorientiert, lösen Probleme sehr konkret ohne generischen Ansatz; die anderen präferieren es, zu modellieren, auf Eventualitäten vorbereitet zu sein und eine Lösung möglichst mehrfach zu verwenden. Als Leser können Sie sich bestimmt auch in einer dieser beiden Kategorien wiederfinden. Ich fühle mich eher der letzteren Gruppe zugehörig und möchte mit dieser Artikelserie davon überzeugen, dass ein gut modelliertes Projekt schlicht langlebiger ist, weil geänderte Kundenwünsche einfacher in die Software inkludiert werden können. Im Zeitalter von „Agile“ – was fälschlicherweise sehr oft vom Auftraggeber als „Wir wollen das doch anders!“ interpretiert wird – ist es umso wichtiger, zu Beginn des Projekts die höchstrelevanten Pfeiler der Software richtig zu setzen.

Kluge Menschen aus den Anfängen der objektorientierten Entwicklung haben sich mit der Softwarearchitektur tief gehend beschäftigt und uns sehr nützliche Design Patterns beschert. Unter dem Akronym SOLID werden fünf wichtige Prinzipien zusammengefasst.

Single-Responsibility-Prinzip: Eine Klasse sollte nicht mehr als eine Aufgabe besitzen. So oder so ähnlich wird das im Lehrbuch definiert. Im Gegensatz zur Definition ist die Bedeutung geradezu banal und offensichtlich. Eine Klasse Kunde hat typischerweise eine Methode KundeHinzufügen oder AddCustomer, mit der neue Kunden hinzugefügt werden können. Wenn wir annehmen, innerhalb der Methode einen Fehler abfangen zu können, also quasi eine try-catch-Anweisung implementieren, und im Fehlerfall eine Datei aus dem Dateisystem (per File.WriteAllText(..)) öffnen, um den Fehler zu hinterlegen, wird die Klasse Kunde mehr tun, als nur Kunden zu verwalten. Das Öffnen einer Datei ist semantisch inkorrekt und müsste offensichtlich in eine Log- oder Fileklasse ausgelagert werden. Ziel ist, falls sich beispielsweise der Dateipfad für die Logs ändert, nicht eine unbestimmte Zahl an Klassen zu haben, in der jeweils der Dateipfad geändert werden muss, sondern nur eine einzige Stelle – nämlich die Logging-Klasse.

Open-Closed-Prinzip: Gemäß Lehrbuch bzw. Wikipedia heißt es: „Das Open...

Windows Developer
Teil 1: Dependency Injection in Aktion

Clean Code durch Design Patterns

Vielfach gehört, recherchiert, gelesen und dennoch nicht verstanden: Dependency Injection. Ein mysteriöses Design Pattern mit sehr vielen Benefits, wie wir sehen werden. Nach diesem Artikel verstehen Sie Dependency Injection nicht nur, Sie werden von der Magie überwältigt sein und sie nicht mehr hergeben wollen.

Oğuzhan Açıkgöz


ArtikelserieTeil 1: Dependency Injection in AktionTeil 2: Repository-Pattern-Kapselung der DatenschichtTeil 3: Unit-of-Work-Pattern – schlanke Transaktionen an die Datenbank

Über Softwarearchitektur lässt sich meines Erachtens kein allgemeingültiger Konsens finden, nicht einmal in den kleinsten Entwicklergruppen und den flachsten Hierarchien. Die Begründung dafür ist einfach: Die einen sind sehr zielorientiert, lösen Probleme sehr konkret ohne generischen Ansatz; die anderen präferieren es, zu modellieren, auf Eventualitäten vorbereitet zu sein und eine Lösung möglichst mehrfach zu verwenden. Als Leser können Sie sich bestimmt auch in einer dieser beiden Kategorien wiederfinden. Ich fühle mich eher der letzteren Gruppe zugehörig und möchte mit dieser Artikelserie davon überzeugen, dass ein gut modelliertes Projekt schlicht langlebiger ist, weil geänderte Kundenwünsche einfacher in die Software inkludiert werden können. Im Zeitalter von „Agile“ – was fälschlicherweise sehr oft vom Auftraggeber als „Wir wollen das doch anders!“ interpretiert wird – ist es umso wichtiger, zu Beginn des Projekts die höchstrelevanten Pfeiler der Software richtig zu setzen.

Kluge Menschen aus den Anfängen der objektorientierten Entwicklung haben sich mit der Softwarearchitektur tief gehend beschäftigt und uns sehr nützliche Design Patterns beschert. Unter dem Akronym SOLID werden fünf wichtige Prinzipien zusammengefasst.

Single-Responsibility-Prinzip: Eine Klasse sollte nicht mehr als eine Aufgabe besitzen. So oder so ähnlich wird das im Lehrbuch definiert. Im Gegensatz zur Definition ist die Bedeutung geradezu banal und offensichtlich. Eine Klasse Kunde hat typischerweise eine Methode KundeHinzufügen oder AddCustomer, mit der neue Kunden hinzugefügt werden können. Wenn wir annehmen, innerhalb der Methode einen Fehler abfangen zu können, also quasi eine try-catch-Anweisung implementieren, und im Fehlerfall eine Datei aus dem Dateisystem (per File.WriteAllText(..)) öffnen, um den Fehler zu hinterlegen, wird die Klasse Kunde mehr tun, als nur Kunden zu verwalten. Das Öffnen einer Datei ist semantisch inkorrekt und müsste offensichtlich in eine Log- oder Fileklasse ausgelagert werden. Ziel ist, falls sich beispielsweise der Dateipfad für die Logs ändert, nicht eine unbestimmte Zahl an Klassen zu haben, in der jeweils der Dateipfad geändert werden muss, sondern nur eine einzige Stelle – nämlich die Logging-Klasse.

Open-Closed-Prinzip: Gemäß Lehrbuch bzw. Wikipedia heißt es: „Das Open...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang