wichtige Prinzipen des objektorientierten Softwarearchitekturentwurfs (SOLID)

Separation of Concern

Das Prinzip Separation of Concern oder auch Cross-Cutting Concern (CCC), zu Deutsch „Verantwortlichkeitsprinzip„, beschreibt das Trennen und Kapseln von Aufgaben. D.h. Klassen oder Komponenten haben genau eine Aufgabe, für die sie verantwortlich sind. Mit einem einzelnen Satz (z.B. für die Dokumentation) sollte man die jeweilige Funktion beschreiben können.

• positives Beispiel
  • Ich habe 4 Komponenten: Spiellogik, Spielerverwaltung, Buchhaltung und Statistik
• negatives Beispiel
  • Ich habe 2 Komponenten: SpiellogikUndVerwaltung, BuchhaltungMitStatistik

Open-Closed-Prinzip

Eines der wichtigsten Prinzipien ist das Open-Closed-Prinzip. Es sagt aus, dass Klassen, Strukturen oder Komponenten offen für Erweiterungen, jedoch geschlossen gegenüber Änderungen sind.

• positives Beispiel (Spielerverwaltung)
  • Ich kann neben Anfängern und Profis, ganz leicht (durch Interfaces, Vererbung, etc.) noch Fortgeschrittene, Semiprofi und Veterane verwalten.
• negatives Beispiel (Spielerverwaltung)
  • Ich muss „viele“ Klassen, Array’s oder Listen anpassen, um einen weiteren Spielertyp zuverwalten.

Liskov-Substitution-Prinzip

Das Liskov-Substitution-Prinzip, zu Deutsch „Ersetzbarkeitsprinzip„, sagt aus, dass Methoden einer Oberklasse immer auf alle Unterklassen anwendbar sein müssen.

• positives Beispiel (Spielerverwaltung)
  • Die Oberklasse „Spieler“ hat die Methoden: setName(), setPunktzahl() und savePunktzahl().
  • Alle Unterklassen, wie Anfänger, Fortgeschrittene, Semiprofi oder Veteran, können die Methoden ver- und anwenden.
• negatives Beispiel (Spielerverwaltung)
  • Die Oberklasse „Spieler“ hat die Methoden: setName(), setPunktzahl() und setEMail().
  • Die Unterklasse „unregistrierterSpieler“ kann die Methode setName() und savePunktzahl() nicht ausführen.

Interface-Segregation-Prinzip

Das Prinzip Interface-Segregation-Prinzip beschreibt das Aufteilen einer großen Schnittstelle auf einzelne Konsumenten / Clients. Dabei wird zum Beispiel für jeden Konsumenten ein spezielles Interface geschrieben, was genau seine Anforderungen abdeckt. Damit verhindert man das Implementieren nicht gebrauchter Methoden.

• positives Beispiel
  • Die Schnittstelle der Spielerverwaltung zur Spiellogik und Buchhaltung besteht aus zwei Interfaces mit unterschiedlichen Methoden und Attributen.
• negatives Beispiel
  • Die Schnittstelle der Spielerverwaltung zur Spiellogik und Buchhaltung besteht aus einem Interface mit vielen Methoden und Attributen.

Dependency-Inversion-Prinzip

Das Dependency-Inversion-Prinzip beschäftigt sich mit der Verminderung der Kopplung von Paketen/Modulen. Dabei sollten Abhängigkeiten immer von konkreteren Modulen niedriger Ebenen zu abstrakten Modulen höherer Ebenen gerichtet sein. Dies kann zum Beispiel durch das Einziehen von Interfaces erreicht werden.

• positives Beispiel
  • Die Buchhaltung kann alle Spielertypen (z.B. SpielerInterface) verwalten.
• negatives Beispiel
  • Die Buchhaltung verwendet die Klassen Anfänger und Profi.

Eselsbrücke / Merkspruch

Um sich die 5 Prinzipien merken zu können, gibt es die Eselsbrücke / den Merkspruch „SOLID“.
Separation of Concern
Open-Closed-Prinzip
Liskov-Substitution-Prinzip
Interface-Segregation-Prinzip
Dependency-Inversion-Prinzip

Buchemfehlung

Weitere Links

• Wikipedia

Copyright © 2012 AxxG – Alexander Gräsel