Date post: | 06-Apr-2015 |
Category: |
Documents |
Upload: | leonhard-reffner |
View: | 124 times |
Download: | 0 times |
SRP Single Responsibility
Principle
OCP Open Closed Principle
LSP Liskov Substitution
Principle
DIP Dependency Inversion Principle
ISP Interface Segregation Principle
Software Development Principles
SingleResponsibilit
yPrinciple
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
Rectangle
+draw()+area(): double
GUI
Graphical ApplicationGeometry Application
Single Responsibility Principle
Geometric Rectangle
+area(): double
Graphical Rectangle
+draw()
Geometry App Graphical App
GUI_
Open Close
dPrinciple
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(){ returnpreisRechner.Preis();
}
IPreisRechner
+Preis(): double
A
+Preis(): double
B
+Preis(): double
C
+Preis(): double
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.
SubstitutionPrinciple
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.
DependencyInversion
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
Policy Layer
Mechanism Layer
Utility Layer
Dependency Inversion Principle
Policy
Policy Implementation Policy Interface<<interface>>
Mechanism
Utility
Mechanism ImplementationMechanism Interface
<<interface>>
Utility Implementation
InterfaceInterfaceSegregatioSegregationnPrinciplePrinciple
Interface Segregation Principle
Clients sollten nicht gezwungen werden von Methoden abhängig zu sein die sie nicht benötigen.
Segregation = Abtrennung
Interface Segregation Principle
Transaction<<abstract>>
Deposit Transaction Withdrawal Transaction Transfer Transaction
UI<<interface>>
+RequestDepositAmount()+RequestWithdrawalAmount()+RequestTransferAmount()+InformInsufficientFunds()
Interface Segregation Principle
Deposit Transaction Withdrawal Transaction Transfer Transaction
Transaction<<abstract>>
UI
+RequestDepositAmount()+RequestWithdrawalAmount()+RequestTransferAmount()+InformInsufficientFunds()
Deposit UI<<interface>>
+RequestDepositAmount()
Withdrawal UI<<interface>>
+RequestWithdrawalAmount()+InformInsufficientFunds()
Transfer UI<<interface>>
+RequestTransferAmount()
Links und Infos
Robert C. MartinAgile Software DevelopmentISBN 0-13-597444-5