Software Development Principles Stefan Lieser Web:

SRPSingle Responsibility Principle OCPOpen Closed Principle LSPLiskov Substitution Principle DIPDependency Inversion Principle ISPInterface Segregation Principle Software Development Principles

Single Responsibility Principle

Single Responsibility Principle Eine Klasse sollte nur einen Grund für Änderungen haben. Auch als Cohesion bezeichnet Zusammenhang Kohäsion Hat eine Klasse mehr als einen Verantwortungsbereich, dann gibt es mehrere Gründe für Änderungen, sind diese Verantwortungsbereiche gekoppelt.

Single Responsibility Principle

Open Closed Principle

Open Closed Principle

Open-Closed Principle Klassen sollen offen für Erweiterungen sein aber geschlossen für Modifikationen. Beispiel Preisberechnung Preisberechnung in die Klasse integriert: Klasse muss geändert werden um neue Variante der Preisberechnung zu integrieren. Berechnung extern (Strategy Pattern): Klasse ist offen für Erweiterungen ohne dass sie selbst modifiziert werden muss.

Replace Conditional With Strategy public double Preis(){ if (...) return... else if (...) return... else if (...) return... else return... } public double Preis(){ return preisRechner.Preis(); }

Replace Conditional With Strategy Vorteile Testbarkeit wird verbessert Die Strategy Klassen können einzeln getestet werden. Andernfalls müssen Testdaten erzeugt werden um jedes Conditional auszuführen. Erweiterbarkeit wird verbessert Folge des Open-Closed Principle Wiederverwendbarkeit wird verbessert Die Strategy Klassen können auch an anderer Stelle verwendet werden.

Substitution Principle Liskov

Normteile

Liskov Substitution Principle Subtypes müssen sich so verhalten wie ihr Basetype. Der Subtype darf den Basetype nicht einschränken sondern nur erweitern. Beispiel: F(A) B : A Wenn B eine Exception auslöst obwohl A dies nicht macht entsteht in F ein Problem.

Dependency Inversion Principle

Dependency Inversion Principle High level Klassen sollten nicht von low level Klassen abhängig sein. Beide sollten von Interfaces abhängig sein. Interfaces sollten nicht von Details abhängen sondern Details von Interfaces.

Dependency Inversion Principle

InterfaceSegregation Principle

Interface Segregation Principle Clients sollten nicht gezwungen werden von Methoden abhängig zu sein die sie nicht benötigen. Segregation = Abtrennung

Interface Segregation Principle

Links und Infos Robert C. Martin Agile Software Development ISBN