Software Development Principles

Stefan Lieser

Mail: stefan@lieser-online.deWeb: http://lieser-online.de

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