Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
1
Software Development Principles Stefan Lieser Mail:stefan@lieser-online.destefan@lieser-online.de Web:http://lieser-online.dehttp://lieser-online.de
3
SRPSingle Responsibility Principle OCPOpen Closed Principle LSPLiskov Substitution Principle DIPDependency Inversion Principle ISPInterface Segregation Principle Software Development Principles
5
Single Responsibility Principle
6
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.
7
Single Responsibility Principle
9
Open Closed Principle
10
Open Closed Principle
11
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.
12
Replace Conditional With Strategy public double Preis(){ if (...) return... else if (...) return... else if (...) return... else return... } public double Preis(){ return preisRechner.Preis(); }
13
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.
14
Substitution Principle Liskov
15
Normteile
16
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.
17
Dependency Inversion Principle
18
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.
19
Dependency Inversion Principle
21
InterfaceSegregation Principle
22
Interface Segregation Principle Clients sollten nicht gezwungen werden von Methoden abhängig zu sein die sie nicht benötigen. Segregation = Abtrennung
23
Interface Segregation Principle
25
Links und Infos Robert C. Martin Agile Software Development ISBN 0-13-597444-5
Ähnliche Präsentationen
