Die Kunst des Software Design - Java

Die Kunst des Software-Design
oder was Software-Entwickler von der Tierwelt lernen können

1&1 Internet AG, 8. Februar 2011
Holger Rüprich und Stephan Schmidt

Holger Rüprich

• Head of Sales Processes Access
bei der 1&1 Internet AG

• Clean Code Enthusiast

• Gast-Dozent an der Berufs-
Akademie Mosbach

• Autor für die Zeitschrift T3N

Stephan Schmidt

• Head of Web Sales Development
bei der 1&1 Internet AG

• Design Patterns Enthusiast

• Autor von PHP Design Patterns
sowie anderen Büchern und über
30 Fachartikeln

• Redner auf internationalen
Konferenzen

Software Design

„Software Design is a process of problem solving
and planning for a software solution.“
Wikipedia

Kunst

„Das Wort Kunst bezeichnet im weitesten Sinne
jede entwickelte Tätigkeit, die auf Wissen, Übung,
Wahrnehmung, Vorstellung und Intuition
gegründet ist.“
Wikipedia

Ziele von Software Design

Stabilität Sicherheit Flexibilität Performance

Das Eichhörnchen

Kapsle Daten und Algorithmen.

Von der realen Welt ...

• Bob hat eine Autovermietung

• Er muss Autos einkaufen

• Er vermietet unterschiedliche
Modelle

• Er vermietet Autos zu verschiedenen
Preisen

... zur programmierten Welt

• Klassen übertragen Dinge aus der realen Welt in die programmierte Welt

public class Car {

private String manufacturer;
private String color;
private float milage;
private boolean engineStarted;

public void startEngine() {}
public void driveForward(float miles) {}
public void stopEngine() {}
public String getManufacturer() {}
public String getColor() {}
public float getMilage() {}

}

Kapsle den Zugriff auf Daten

Kapsle den Zugriff auf Daten immer innerhalb
einer Klasse und biete Methoden an, um diese
Daten abzufragen.
public class Car {

... Eigenschaften und Methoden ...

public double getDailyRate(int days) {
return 75.5;
}
}

Kapsle den Zugriff auf Daten

Kapsle den Zugriff auf Daten immer innerhalb
einer Klasse und biete Methoden an, um diese
Daten abzufragen.
public class Car {

... Eigenschaften und Methoden ...

public double getDailyRate(int days) {
if (days >= 7) {
return 65.9;
}
return 75.5;
}
}

Bobs Kunden

public class Customer {

private int id;
private String name;

public Customer(int id, String name) {
this.id = id;
this.name = name;
}

public int getId() {
return id;
}

public String getName() {
return name;
}

}

Bobs Firma

public class RentalCompany {

Map<String, Vehicle> fleet = new HashMap<String, Vehicle>();

public void addToFleet(String id, Vehicle vehicle) {
fleet.put(id, vehicle);
}

public RentalAction rentVehicle(Vehicle vehicle, Customer customer) {}

public boolean returnVehicle(Vehicle vehicle) {}

}

Bobs Geschäft

• Klassen übertragen nicht nur physikalische Dinge, sondern auch Abläufe

public class RentalAction {
... Eigenschaften ...

public RentalAction(Vehicle vehicle, Customer customer) {
this(vehicle, customer, new Date());
}

public RentalAction(Vehicle vehicle, Customer customer, Date date) {
this.vehicle = vehicle;
this.customer = customer;
this.rentDate = date;
}

... Getter ...
}

Bobs Geschäft

• Klassen übertragen nicht nur physikalische Dinge, sondern auch Abläufe

public class RentalAction {
...

public void markCarReturend() {
markCarReturend(new Date());
}

public void markCarReturend(Date date) {
returnDate = date;
}

public boolean isReturend() {
return returnDate != null;
}
}

Kapsle auch Algorithmen

Kapsle nicht nur Daten sondern auch Algorithmen
in den Methoden deiner Klassen, um komplexe
Operationen zentral an einer Stelle zu
implementieren.

Bobs Firma


...

public RentalAction rentVehicle(Vehicle vehicle, Customer customer) {
if (!fleet.containsValue(vehicle)) {
throw new UnknownVehicleException();
}

if (!vehicleIsAvailable(vehicle)) {
throw new VehicleNotAvailableException();
}

RentalAction rentalAction = new RentalAction(vehicle, customer);
rentalActions.add(rentalAction);
return rentalAction;
}

}

Bobs Firma


...

private boolean isVehicleAvailable(Vehicle vehicle) {

for (RentalAction rentalAction : rentalActions) {

if (rentalAction.getVehicle().equals(vehicle)
&& !rentalAction.isReturend()) {
return false;
}

}

return true;
}

}

Bobs Firma


...

public boolean returnVehicle(Vehicle vehicle) {

for (RentalAction rentalAction : rentalActions) {

if (rentalAction.getVehicle().equals(vehicle)
&& !rentalAction.isReturend()) {
rentalAction.markCarReturend();
return true;
}

}

return false;
}

}

Die Weisheit des Eichhörnchens

Schütze deine Daten.
Verberge Implementierungsdetails und unterbinde den Zugriff auf
interne Datenstrukturen.
Wähle Klassen- und Methodennamen sinnvoll
und achte darauf, dass der resultierende Code
sich wie ein Satz lesen lässt.

Das Krokodil

Achte das Single-Reponsibility-Prinzip.

Das Single-Responsibility-Prinzip

„There should never be more than one reason for
a class to change“
Robert C. Martin

Bob will wissen was los ist


System.out.println("Neues Auto im Fuhrpark: " + vehicle.getManufacturer());
}

public void rentVehicle(Vehicle vehicle, Customer customer) {
System.out.println("Neuer Mietvorgang: " + customer.getName() + " leiht " +
vehicle.getManufacturer());
}

}

> Neues Auto im Fuhrpark: BMW
> Neuer Mietvorgang: Stephan Schmidt leiht BMW
> Rückgabe: Stephan Schmidt gibt BMW zurück
> Neuer Mietvorgang: Gerd Schaufelberger leiht BMW

Bob will wissen was los ist



} Was ist mit Problemen im Produktivbetrieb?
System.out.println("Neues Auto im Fuhrpark: " + vehicle.getManufacturer());

}

}

> Neues Auto im Fuhrpark: BMW
> Neuer Mietvorgang: Stephan Schmidt leiht BMW
> Rückgabe: Stephan Schmidt gibt BMW zurück
> Neuer Mietvorgang: Gerd Schaufelberger leiht BMW

Debugging im Produktivbetrieb

switch (DEBUG_MODE) {
case ECHO:
System.out.println("Neues Auto im Fuhrpark: "+vehicle.getManufacturer());
break;
case LOG:
default:
logger.info("Neues Auto im Fuhrpark: " + vehicle.getManufacturer());
break;
}
}

case ECHO:
break;
case LOG:
default:
logger.info("Neuer Mietvorgang: " + customer.getName() + " leiht " +
break;
}
}

Debugging im Produktivbetrieb

case ECHO:
System.out.println("Neues Auto im Fuhrpark: "+vehicle.getManufacturer());
break;
case LOG:
default:
logger.info("Neues Auto im Fuhrpark: " + vehicle.getManufacturer());

}
break; Code Duplizierung macht die Anwendung
}
langsamer und schwerer zu warten
case ECHO:
break;
case LOG:
default:
logger.info("Neuer Mietvorgang: " + customer.getName() + " leiht " +
break;

Wiederverwendbarkeit statt Copy-and-Paste


debug("Neues Auto im Fuhrpark: " + vehicle.getManufacturer());
}

debug("Neuer Mietvorgang: " + customer.getName() + " leiht " +
}

...

}


...

private void debug(String message) {
case ECHO:
System.out.println(message);
break;
case LOG:
default:
logger.info(message);
break;
}
}
}


...

Weitere Debugging-Ziele, wie E-Mails oder SMS,
private void debug(String message) {
machen die debug()-Methode komplexer
case ECHO:
break;
case LOG: und somit fehleranfälliger.
default:
logger.info(message);
break;
}
}

Atomare Probleme lösen

public abstract class RentalCompany {
... Eigenschaften und Methoden der Klasse ...

protected abstract void debug(String message);
}

public class EchoingRentalCompany extends RentalCompany {
protected void debug(String message) {
}
}

public class LoggingRentalCompany extends RentalCompany {
protected void debug(String message) {
Logger.getAnonymousLogger().info(message);
}
}


RentalCompany company;

case ECHO:
company = new EchoingRentalCompany();
break;
case LOG:
default:
company = new LoggingRentalCompany();
break;
}

Car bmw = new Car("BMW", "blau");
Customer stephan = new Customer(1, "Stephan Schmidt");
Customer gerd = new Customer(2, "Gerd Schaufelberger");

company.addToFleet("bmw1", bmw);
company.rentVehicle(bmw, stephan);
company.returnVehicle(bmw);


RentalCompany company;

case ECHO:
company = new EchoingRentalCompany();
break;
case LOG:
Die debug()-Methode steht nur Unterklassen von
default:
company = new LoggingRentalCompany();

}
break;
RentalCompany zur Verfügung.
Car bmw = new Car("BMW", "blau");
Customer stephan = new Customer(1, "Stephan Schmidt");
Customer gerd = new Customer(2, "Gerd Schaufelberger");

company.addToFleet("bmw1", bmw);
company.rentVehicle(bmw, stephan);
company.returnVehicle(bmw);

Komposition statt Vererbung

public interface Debugger {
void debug(String message);
}

public class DebuggerEcho implements Debugger { {
public void debug(String message) {
}
}

public class DebuggerLog implements Debugger {
}
}


class RentalCompany {
... Eigenschaften der Klasse ...

public RentalCompany() {
case ECHO:
debugger = new DebuggerEcho();
break;
case LOG:
default:
debugger = new DebuggerLog();
break;
}
}

debugger.debug("Neues Auto im Fuhrpark: " + vehicle.getManufacturer());
}

...
}

Die Weisheit des Krokodils

Teile und herrsche.
Jedes Modul soll genau eine Verantwortung übernehmen, und jede
Verantwortung soll genau einem Modul zugeordnet werden.

Die Schildkröte

Achte das Open-Closed-Prinzip.

Das Open-Closed-Prinzip

„Software entities (classes, modules, functions,
etc.) should be open for extension, but closed for
modification.“
Bertrand Meyer



public RentalCompany() {
case ECHO:
debugger = new DebuggerEcho();
break;
case LOG:
default: Die RentalCompany Klassen ist von
anderen Klassen abhängig
debugger = new DebuggerLog();
break;
}
}

debugger.debug("Neues Auto im Fuhrpark: " + vehicle.getManufacturer());
}

...
}

Einsatz von Interfaces


public RentalCompany(Debugger debugger) {
this.debugger = debugger;
}

... weitere Methoden der Klasse ...
}

Debugger debugger = new DebuggerEcho();
RentalCompany company = new RentalCompany(debugger);

Die Weisheit der Schildkröte

Schütze deinen Code.
Programmiere immer gegen Schnittstellen, nie gegen eine konkrete
Implementierung.
Vermeide feste Abhängigkeiten zwischen einzelnen Klassen deiner
Anwendungen und ziehe immer lose Kopplung der Klassen vor.

Der Erpel

Achte das Hollywood-Prinzip.

Das Hollywood Prinzip

„Rufen Sie uns nicht an, wir werden Sie anrufen.“


• Auch bekannt als „Inversion of
Control“

• Objekte sollen sich ihre
Abhängigkeiten nicht selbst holen
oder erzeugen

• Objekte sollen unabhängig von ihrer
Umgebung sein

Dependency Injection

• Objekte erstellen abhängige Objekte nicht selbst

• Abhängige Objekte werden von außen über den Konstruktor (Constructor
Injection) oder über Setter-Methoden (Setter Injection) injiziert

• Abhängige Objekte sind dadurch sehr leicht austauschbar

Dependency Injection
Debugger debugger = new DebuggerEcho();
RentalCompany company = new RentalCompany(debugger); Constructor Injection
Logger logger = new DateTimeLogger();
RentalCompany company.setLogger(logger); Setter Injection

• RentalCompany weiß weder, welche Implementierung des Debugger-Interface
noch welche Implementierung des Logger-Interface sie verwendet

• RentalCompany steuert nicht, wie sie an ihre Abhängigkeiten kommt, der
Kontrollﬂuss wird von außerhalb gesteuert

• Aber: Sehr viel zusätzlicher Client Code, durch Instanziieren und Injizieren der
Objekte nötig

Inversion-of-Control-Container

• Verringern den nötigen Boilerplate-Code

• Code, der nur nötig ist, um die Objekte zu „verdrahten“

• In der Java-Welt schon weit verbreitet

• Spring, Google Guice, Tapestry IoC, ...

Google Guice

• Basiert komplett auf Java-Code

• Keine externe Konﬁguration

• Stattdessen Einsatz von Annotations

• Sehr leichtgewichtig

Rufen Sie Bob nicht an, Bob ruft sie an.


@Inject
public void setLogger(Logger logger) { Setter Injection
this.logger = logger;
}

...

}

Interfaces binden

• Typen werden durch Modul an konkrete Implementierungen gebunden:

public class RentalCompanyModule extends AbstractModule {
@Override
protected void configure() {
bind(Debugger.class).to(DebuggerEcho.class);
}
}

• Guice kann Injector liefern, der Instanzen erzeugt:

Injector injector = Guice.createInjector(new RentalCompanyModule());
Debugger debugger = injector.getInstance(Debugger.class);
debugger.debug("Debugging with Guice.");

// Injiziert Debugger auch in andere Objekte
RentalCompany company = injector.getInstance(RentalCompany.class);
Car bmw = new Car("BMW", "silver");
company.addToFleet("bmw", bmw);

Komplexeres Beispiel

• Neuer Typ „Formatter“, inkl. Implemetierungen:

public interface Formatter {
public String format(String s);
}

public class ReverseFormatter implements Formatter {
public String format(String s) {
return new StringBuffer(s).reverse().toString();
}
}

public class UppercaseFormatter implements Formatter {
public String format(String s) {
return s.toUpperCase();
}
}


• Einsatz in DebuggerEcho:

public class DebuggerEcho implements Debugger {
Formatter formatter;

@Inject
public DebuggerEcho(Formatter formatter) {
this.formatter = formatter;
}

@Override
System.out.println(this.formatter.format(message))
}
}


• Und Einsatz in MyApplication:

public class MyApplication {
private Debugger debugger;
private Formatter formatter;

@Inject
public MyApplication(Debugger debugger) {
}

@Inject
public void setFormatter(Formatter f) {
formatter = f;
}

public void doSomething(String s) {
s = this.formatter.format(s);
System.out.println("Sending '" + s + "' to Debugger.");
this.debugger.debug(s);
}
}


• Benannte Injections:

public class MyApplication {
private Debugger debugger;
private Formatter formatter;

@Inject
public MyApplication(Debugger debugger) {
}

@Inject
public void setFormatter(@Named("myFormatter") Formatter f) {
formatter = f;
}

public void doSomething(String s) {
s = this.formatter.format(s);
System.out.println("Sending '" + s + "' to Debugger.");
this.debugger.debug(s);
}
}


• Und jetzt die Bindings dazu:

public class MyApplicationModule extends AbstractModule {

@Override
protected void configure() {
bind(Debugger.class).to(DebuggerEcho.class);
bind(Formatter.class).to(UppercaseFormatter.class);
bind(Formatter.class).annotatedWith(Names.named("myFormatter")).
to(ReverseFormatter.class);
}
}

• Und jetzt die Bindings dazu:
Injector injector = Guice.createInjector(new MyApplicationModule());
MyApplication app = injector.getInstance(MyApplication.class);
app.doSomething("Hollywood");


Was wird jetzt ausgegeben?


• Ausgabe des Beispiels

Sending 'doowylloH' to Debugger.
DOOWYLLOH

DebuggerEcho UppercaseFormatter

MyApplication

ReverseFormatter

Weitere Features von Guice

• Verwenden einer Standardimplementierung.

• Objekte in einem Scope erzeugen, z.B. Singleton.

• Typen an Provider binden, die dann die tatsächlichen Objekte benötigen.

• Primitive Typen binden.

• Unterstützung für eigene Binding-Annotations.

Das selbe nochmal, mit Spring

• Konﬁguration über XML:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="...">

<bean id="application" class="net.schst.tiercode.ioc.spring.MyApplication">
<constructor-arg ref="echo-debugger"/>
<property name="formatter" ref="reverse-formatter"/>
</bean>

<bean id="reverse-formatter" class="net.schst.tiercode.ioc.spring.ReverseFormatter">
</bean>

<bean id="uppercase-formatter" class="net.schst.tiercode.ioc.spring.UppercaseFormatter">
</bean>

<bean id="echo-debugger" class="net.schst.tiercode.ioc.spring.DebuggerEcho">
<constructor-arg ref="uppercase-formatter"/>
</bean>

</beans>

Das selbe nochmal, mit Spring

• Erzeugen der Beans
ApplicationContext context = new ClassPathXmlApplicationContext("spring/spring-beans.xml");
MyApplication app = context.getBean("application", MyApplication.class);

• Ausgabe:

DOOWYLLOH

Dasselbe nochmal, mit XJConf

• Tag-Deﬁnitionen über XML:
<defines>
<tag name="EchoDebugger"
type="net.schst.tiercode.ioc.xjconf.DebuggerEcho" setter="setDebugger"/>

<tag name="ReverseFormatter"
type="net.schst.tiercode.ioc.xjconf.ReverseFormatter" setter="setFormatter"/>

<tag name="UppercaseFormatter"
type="net.schst.tiercode.ioc.xjconf.UppercaseFormatter" setter="setFormatter"/>

<tag name="Application" type="net.schst.tiercode.ioc.xjconf.MyApplication"/>
</defines>

• Nicht ganz dasselbe:

• XJConf ist schlecht bei Constructor-Injection. Also alles auf Setter-Injection
umgestellt.


• Deﬁnition der Objekte über XML:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<Application>
<EchoDebugger>
<UppercaseFormatter/>
</EchoDebugger>
<ReverseFormatter/>
</Application>
</configuration>


• Erzeugen der Objekte:
DefinitionParser tagParser = new DefinitionParser();
NamespaceDefinitions defs = tagParser.parse(".../xjconf/defines/defines.xml");

XmlReader conf = new XmlReader();
conf.setTagDefinitions(defs);

conf.parse("src/main/resources/xjconf/conf/conf.xml");
MyApplication app = (MyApplication) conf.getConfigValue("Application");

• Ausgabe:

DOOWYLLOH

Die Weisheit des Erpel

Verwende ein DI Framework.
Erleichtere dir das Verwalten von komplexen Objektstrukturen
durch den Einsatz eines Dependency Injection Frameworks.

Die Biene

Nutze Design Patterns.

Konkretes Problem

„Ich möchte Debug-Meldungen auf verschiedene
Arten verarbeiten und diese auswechseln können,
ohne den Code der RentalCompany Klasse
anpassen zu müssen.“
Bob

Abstraktes Problem

„Ich möchte eine Aufgabe mit verschiedenen
Algorithmen lösen können. Jede der Lösungen soll
gekapselt sein und nichts von den anderen wissen.
Die einzelnen Lösungen sollen gegeneinander
austauschbar sein, ohne den nutzenden Client
anzupassen.“
Abstract Bob

Konkret vs Abstrakt

Abstrakt Konkret

Verarbeiten von Debug-
Aufgabe
Meldungen

Ausgeben per print(),
Algorithmen
Schreiben eines Logﬁles

Die Klasse
Client
RentalCompany

Konkret vs Abstrakt

Abstrakt Konkret

Persistieren von
Aufgabe
Gästebucheinträgen

Speichern in Datenbank,
Algorithmen
Speichern in XML-Datei

Client Die Klasse Guestbook

Bobs erstes Design Pattern

Strategy-Pattern

Design Patterns

• Lösungsmuster für häuﬁg auftretende Entwurfsaufgaben in der Software-
Entwicklung

• Keine Code-Bibliothek

• Organisiert in Pattern-Katalogen (z.B. Gang-of-Four Buch)

• Verschiedene Kategorien: Erzeugungsmuster, Strukturmuster,
Verhaltensmuster, Enterprise-Patterns

Erzeugungsmuster

• Erzeugungsmuster werden verwendet, um Objekte zu konstruieren.

• Zu den Erzeugungsmustern gehöhren unter anderem

• Singleton-Pattern

• Factory-Method-Pattern

• Prototype-Pattern

• Abstract-Factory-Pattern

Factory-Method-Pattern

• Deﬁniert eine Schnittstelle zur Erzeugung von Objekten

• Verlagert die eigentliche Instanziierung in Unterklassen

• Lässt Unterklassen entscheiden, welche konkrete Implementierung
verwendet wird


public abstract class AbstractManufacturer<T extends Vehicle> {

protected String name;

public AbstractManufacturer(String name) {
this.name = name;
}

public T sellVehicle() {
return manufactureVehicle();
}

protected abstract T manufactureVehicle();

}


public class CarManufacturer extends AbstractManufacturer<Car> {

protected Car manufactureVehicle() {
return new Car(name, "black");
}

}

CarManufacturer bmwManufacturer = new CarManufacturer("BMW");
Car bmw = bmwManufacturer.sellVehicle();


Das Factory-Method-Pattern definiert eine
Schnittstelle zur Erzeugung von Objekten. Es
verlagert aber die eigentliche Instanziierung in
Unterklassen; es lässt die Unterklassen
entscheiden, welche konkreten
Implementierungen verwendet werden.

der abstrak
lichen Objekte zu
4. Verwenden Sie nun diese konk reten Unterklassen, um die tatsäch
ementierungen zu
instanziieren und Ihren Applik ationscode von den konkreten Impl
lösen.
fach darauf, die
verwenden möchten, achten Sie ein
Wann immer Sie eine Fabrikmetho
de
hier gezeigten Schritte durchzuführe
n, und dem Erfolg Ihres Vorhabens
steht nichts mehr
teiligten des Fac-
n die Beziehungen zwischen den Be
im Weg. Abbildung 4-2 zeigt Ihne f die Erzeugung der
tory-Method-Patterns und illustri ert noch einmal, wie das Pattern au
cle-Implementierungen angewa
ndt wurde.
Vehi

sell Vehicle-Methode, ruft
Vehicle-Interface Fabrikmethode auf
Creator
Product

+FactoryMethod() : Product
+MethodA()

AbstractManufacturer- CarManufacturer und
Klasse ConvertibleManufacturer

ConcreteCreator
ConcreteProduct

+FactoryMethod() : Product

Implementierungen des Vehicle- Fabrikmethode manufactureVehicle
anzen
Interfaces wie Car, Convertible et
c. erzeugt Car- bzw. Convertible-Inst

s Factory-Method-Patterns
Abbildung 4-2: UML-Diagramm de

Das Factory-Method-Pattern | 177

Prototype-Pattern

• Das Prototype-Pattern erzeugt Objekte durch das Kopieren eines
prototypischen Exemplars

• Es ermöglicht das Hinzufügen neuer "Klassen" zur Laufzeit ohne
Programmierung

• Es hält die Anzahl der benötigten Klassen klein

Prototype-Pattern

public class SpecialEditionManufacturer {

protected Map<String, Vehicle> prototypes = new HashMap<String, Vehicle>();

public void addSpecialEdition(String edition, Vehicle prototype) {
prototypes.put(edition, prototype);
}

public Vehicle manufactureVehicle(String edition) throws
UnknownSpecialEditionException {

if (prototypes.containsKey(edition)) {
return prototypes.get(edition).clone();
}

throw new UnknownSpecialEditionException(
"No prototype for special edition " + edition + " registered.");
}

}

Prototype-Pattern

SpecialEditionManufacturer manufacturer = new SpecialEditionManufacturer();

Car golfElvis = new Car("VW", "silber");
golfElvis.setAirConditioned(true);
golfElvis.setGraphics("Gitarre");
manufacturer.addSpecialEdition("Golf Elvis Presley Edition", golfElvis);

Convertible golfStones = new Convertible("VW", "rot");
golfStones.setAirConditioned(false);
golfStones.setGraphics("Zunge");
manufacturer.addSpecialEdition("Golf Rolling Stones Edition", golfStones);

Vehicle golf1 = manufacturer.manufactureVehicle("Golf Elvis Presley Edition");
Vehicle golf2 = manufacturer.manufactureVehicle("Golf Rolling Stones Edition");

Prototype-Pattern

Das Prototyp-Muster bestimmt die Arten der zu
erzeugenden Objekte durch die Verwendung eines
prototypischen Exemplars, das zur Erzeugung
neuer Instanzen kopiert wird.

Prototype-Pattern
!!"""#$#"%&'()*+,,-../0120.)!!..3
4012567.8*.95:;54.)!!8..<<='&.<<

Vehicle-Interface

SpecialEditionManufacturer __clone()-Methode
kennt alle verfügbaren in PHP nicht immer nötig
Prototypen

rface wie
Implementierungen des Vehicle-Inte
Car, Convertible etc.

e-Patterns
Abbildung 4-6: UML-Diagramm des Prototyp
plikation
reduziert die Anzahl der Klassen, die Ihre Ap
Der Einsatz des Prototype-Patterns ukte zu
sen bild en müssen, um die einzelnen Prod
benötigt, da Sie weniger Unterklas en von einer Klasse
erzeugen. Stattdessen werden al le Produkte auf Basis der Prototyp

Strukturmuster

• Strukturmuster befassen sich mit der Komposition von Objekten

• Zu den Strukturmustern gehören unter anderem

• Composite-Pattern

• Proxy-Pattern

• Adapter-Pattern

• Facade-Pattern

Composite-Pattern

• Lässt mehrere Instanzen eines Typs nach außen wie eine Instanz aussehen

• Implementieren einer neuen Klasse, die die einzelnen Instanzen aufnimmt

• Muss die selbe Schnittstelle implementieren wie die entsprechenden
Instanzen

Composite-Pattern

public interface Debugger {
void debug(String message);
}

public class DebuggerEcho implements Debugger { {
}
}

public class DebuggerLog implements Debugger {
}
}

Composite-Pattern

public class CompositeDebugger implements Debugger {

protected List<Debugger> debuggers = new ArrayList<Debugger>();

public void addDebugger(Debugger debugger) {
debuggers.add(debugger);
}

for (Debugger debugger : debuggers) {
debugger.debug(message);
}
}

}

CompositeDebugger compositeDebugger = new CompositeDebugger();
compositeDebugger.addDebugger(new DebuggerEcho());
compositeDebugger.addDebugger(new DebuggerLog());

Composite-Pattern

Das Composite-Pattern fügt mehrere Objekte zu
einer Baumstruktur zusammen und ermöglicht es,
diese von außen wie ein einzelnes zu verwenden.

Composite-Pattern
!!"""#$#"%&'()*+,,-../0120.)3)..45
012678.9*.:6;<65.)!!9..33='&.33

DebuggerComposite kann
Debugger-Schnittstelle mit beliebig viele Debugger
Methode debug() speichern
Component

+methodA()
+methodB()
Konkrete Debugger-
Implementierungen

Composite
ConcreteComponent

+addChild(child : Component)
+methodA()
+removeChild(child : Component)
+methodB()
+methodA()
+methodB()

DebuggerComposite-Klasse debug()-Methode delegiert
Aufruf an die anderen Debugger

s Composite-Patterns
Abbildung 5-3: UML-Diagramm de

Weitere Anwendungen e Anwendung des
haben Sie bereits eine sehr beliebt
Mit der Debugging-Funktionalität e ähnliche
etet das PEAR-Paket Log , das ein
2
Kompositum-Patterns kenn engelernt. So bi si-
llt, auch eine Klasse, die als Kompo

Adapter-Pattern

• Das Adapter-Pattern passt die Schnittstelle eines Objekts an die vom Client
erwartete Schnittstelle.

• Es erleichtert die Nutzung von Fremdcode in eigenen Systemen.

• Das Adapter-Pattern arbeitet ähnlich wie ein Adapter für Steckdosen.

Adapter-Pattern

public class Automobile {

private boolean ignited;
private float milesDriven;

public void drive(Direction direction, float miles) throws
AutomobileException {

if (ignited) {
milesDriven += miles;
} else {
throw new AutomobileException("ZŸndung ist nicht an.");
}
}

...
}

Adapter-Pattern

public class AutomobileAdapter implements Vehicle {

protected Automobile automobile;

public AutomobileAdapter(Automobile automobile) {
this.automobile = automobile;
}

public boolean moveForward(float miles) {
try {
automobile.drive(Direction.FORWARD, miles);
return true;
} catch (AutomobileException e) {
return false;
}
}

...
}

Adapter-Pattern

Das Adapter-Muster passt die Schnittstelle einer
Klasse an die vom Client erwartete Schnittstelle
an. Es ermöglicht die Zusammenarbeit von
Klassen, die eigentlich aufgrund inkompatibler
Schnittstellen nicht zusammenarbeiten können.

Sie die Anf
von Fehlern.
5. Beachten Sie Unterschiede beim Signalisieren
prungsobjekt zu
ion das Adapter-Objekt, um das Urs
6. Verwenden Sie in Ihrer Applikat
ummanteln.
Adapter-Pattern
Wenn Sie diese einfachen Schritte
Ab
befolgen, adaptieren Sie leicht die
verschiedensten
bildung 5-4 zeigt Ihnen noch einmal
die am Adap-
Schnittstellen in Ihrer Applikation. oblem der
Interfa ces und wie das Pattern auf das Pr
ter-Pattern beteiligten Klassen und wandt wurde.
abweichenden Schn ittstelle der Automobile-Klasse ange

Klassen, die das Vehicle-
Interface nutzen, z.B. Vehicle-Interface
RentalCompany
Client «interface»
Target
+methodA()
Automobile-Klasse

Adaptee
Adapter

+methodB()
+methodA()

AutomobileAdapter
Adapter ruft die entsprechenden
Methoden auf dem Automobile-
Objekt auf

apter-Patterns
Abbildung 5-4: UML-Diagramm des Ad

Verhaltensmuster

• Verhaltensmuster beschreiben die Interaktion zwischen Objekten.

• Zu den Verhaltensmuster gehören unter anderem

• Subject/Observer-Pattern

• Template-Method-Pattern

• Command-Pattern

• Iterator-Pattern

Template-Method-Pattern

• Deﬁniert die Schritte eines Algorithmus in einer Methode

• Implementierung der einzelnen Schritte bleibt Unterklassen vorbehalten

• Gemeinsames Verhalten muss nur einmal implementiert werden: Änderungen
am Algorithmus nur an einer Stelle notwendig

• Neue Unterklassen müssen nur die konkreten Schritte implementieren


public abstract class AbstractCar implements Vehicle {

public final void inspect() {
System.out.println("FŸhre Inspektion durch");
replaceSparkPlugs();
checkTires();
if (isOilLevelLow()) {
refillOil();
}
}

protected abstract void replaceSparkPlugs();
protected abstract void checkTires();
protected abstract boolean isOilLevelLow();

protected void refillOil() {
System.out.println("FŸlle " + (300 - oilLevel) + "ml …l nach.");
oilLevel = 300;
}

...
}


public class Car extends AbstractCar {

protected void replaceSparkPlugs() {
System.out.println("Ersetze Zündkerzen durch Modell AF34.");
}

protected void checkTires() {
System.out.println("Überprüfe Reifendruck, muss 2,0 bar sein.");
}

protected boolean isOilLevelLow() {
return oilLevel < 200;
}

}


Das Template-Method-Pattern definiert die
Schritte eines Algorithmus in einer Methode und
überlässt die Implementierung der einzelnen
Schritte den Unterklassen. Diese können somit
Teile des Algorithmus modifizieren, ohne dessen
Struktur zu verändern.

!!"""#$#"%&'()*+,,-../0120.)%)..34
012567.8*.95:;54.)!!8..<<='&.<<

AbstractCar-Klasse

AbstractClass

+templateMethod()
#primitiveOperation()
inspect()-Methode, ruft die
abstrakten Methoden auf,
die in Unterklassen implementiert
werden
Car- und Convertible-Klassen
ConcreteClass
Implementieren checkTires
#primitiveOperation() replaceSparkPlugs etc.

e-Method-Patterns
Abbildung 6-2: UML-Diagramm des Templat
ktorieren und
es, gemeinsamen Code herauszufa
Schablonenmethoden ermöglichen n zu müssen.
somit gemeinsames Verhalten nur einmal implementiere

Command-Pattern

• Kapselt einen Auftrag als Objekt.

• Aufträge (Objekte) sind parametrisierbar

• Aufträge können in einer Queue nacheinander abgearbeitet werden

• Aufträge können rückgängig gemacht werden.

Command-Pattern

public interface CarWashCommand {
void execute(Car car);
}

public class CarSimpleWashCommand implements CarWashCommand {
public void execute(Car car) {
System.out.println("Das Auto wird gewaschen");
}
}

public class CarDryingCommand implements CarWashCommand {
public void execute(Car car) {
System.out.println("Das Auto wird getrocknet");
}
}

Command-Pattern

public class CarWash {

protected Map<String, CarWashCommand[]> programs =
new HashMap<String, CarWashCommand[]>();

public void addProgram(String name, CarWashCommand... commands) {
programs.put(name, commands);
}

public void wash(String program, Car car) {
for (CarWashCommand command : programs.get(program)) {
command.execute(car);
}
}

}

Command-Pattern

CarWash wash = new CarWash();

wash.addProgram("standard",
new CarSimpleWashCommand(),
new CarDryingCommand());

wash.addProgram("komfort",
new CarSimpleWashCommand(),
new CarEngineWashCommand(),
new CarDryingCommand(),
new CarWaxingCommand());

Car bmw = new Car("BMW", "silber");
wash.wash("standard", bmw);

Command-Pattern

Das Command-Pattern kapselt einen Auftrag als
Objekt. Dadurch wird ermöglicht, andere Objekte
mit Aufträgen zu parametrisieren, Aufträge in
eine Queue zu stellen oder diese rückgängig zu
machen.

parametrisieren.
t, also das Objekt, das die
Mit Client ist im aktuellen Beispiel die Waschanlage gemein
Warteschlange gestellt
Befehle verwendet. Dabei müs sen die Befehle nicht immer in eine
denkbar, dass nur
des Command-Patterns ist es auch
werden. Bei anderen Anwendungen ausgeführt
i Eint reten einer bestimmten Bedingung
ein Befehl übergeben wird, der be
Command-Pattern
wird. Es handelt sich trotzdem um ein Command-Pattern, da der Au
zeit ausgetauscht werden kann. Ab
ftrag in einer Klasse
bildung 6-3 zeigt
gekapselt wird und somit zur Lauf se miteinander in Verbin-
Ihnen die im Command-Pa ttern beteiligten Akteure und wie die
dung stehen.

CarWash, also CarWashCommand-
die Waschanlage Interface

«interface»
Client Invoker
Command
+execute()

Car-Objekte, die gewaschen
werden

Receiver ConcreteCommand
-state
+execute()
+action()

Konkrete Implementierungen
der Wasch-Befehle, z.B.
CarMotorWashCommand

Command-Patterns
Abbildung 6-3: UML-Diagramm des

290 | Kapitel 6: Verhaltensmuster

Enterprise Patterns

• Kommen aus der Java Welt

• Stark geprägt durch Martin Fowler

• Meistens komplexer als die Gang-of-Four Patterns

• Deswegen ab hier keine Beispiele mehr

• Mehr zu Enterprise Patterns in PHP im Buch "PHP Design Patterns"
http://www.phpdesignpatterns.de

Die Weisheit der Biene

Nutze bestehende Lösungen.
Abstrahiere Deine konkreten Probleme und wende Design Patterns
als Vorlage für Deine Lösung an.

Die Bulldogge

Perfektionismus wird
P-A-R-A-L-Y-S-E buchstabiert

You Ain‘t Gonna Need It (YAGNI)

„Always implement things when you actually
need them, never when you just foresee that you
need them“
Ronald E Jeffries

You Ain‘t Gonna Need It (YAGNI)

• Anforderungen sind in der Software-Entwicklung notorisch ungenau oder
wechselnd

• Ungenaue Anforderungen werden oft durch möglichst ﬂexible und
funktionsfähige Software kompensiert

• Es werden Features entwickelt die keine Anwendung ﬁnden

• Dinge die niemand braucht, haben keinen Wert.

Do the simplest thing that could possibly work.

• YAGNI kann als Ergänzung des XP-Prinzips "Do the simplest thing that could
possibly work." verstanden werden

• Wann ist ein Design am einfachsten?

• Es verkörpert die Absicht des Entwicklers und besteht alle Tests.

• Es enthält kein Duplizierungen.

• Es enthält das Minimum an Klassen und Methoden

Emergenz

„Emergenz ist die spontane Herausbildung von
komplexen Systemen und Strukturen durch eine
Vielzahl von relativ einfachen Interaktionen.“
Wikipedia

Saubere Software durch emergentes Design

• Alle Tests bestehen

• Software muss in erster Linie den gewollten Zweck erfüllen.

• Software, die nicht testbar ist, kann nicht veriﬁziert werden.

• Klassen die dem Single Responsibility Prinzip folgen (auf den Tipp des
Krokodils hören) sind leichter zu testen.

• Je mehr Tests wir schreiben, desto mehr bemühen wir uns Code zu
schreiben, der einfacher zu testen ist.


• Alle Tests bestehen

• Eine starke Kopplung erschwert das Schreiben von Tests

• Je mehr Tests wir schreiben, desto mehr bemühen wir uns, die
Kopplung zu minimieren


• Refactoring nach dem Bestehen eines Tests

• Duplizierten Code eliminieren

• Ausdrucksstärke des Codes verbessern

• Anzahl der Klassen und Methoden minimieren

• Tests sichern das bisherige Ergebnis ab

Vorsicht: Perfekt ist der Feind von "Gut genug"

• Entwickler tendieren dazu Lösungen danach zu analysieren wie elegant und
optimal sie für die Problemstellung sind.

• Software Entwicklung ist kein Schönheitswettbewerb

• Der Code ist klar, ausdrucksstark, gut dokumentiert und getestet. Geht es
noch besser?

• Klar. Aber es er ist gut genug.

• Verschwende keine Zeit auf der Suche nach dem perfekten Design

Permature Optimization

„Premature optimization is the root of all evil“
Donald Knuth

Permature Optimization

• Premature Optimization beschreibt die Situation in der Design
Entscheidungen aufgrund von Performance-Optimierungen getroffen werden

• Solche Optimierungen resultieren oft in unleserlicherem Code

• Michael A. Jackson über Optimierung

• Dont't do it.

• (For experts only) - Don't do it yet

Premature Optimization

• Was wenn Performance-Optimierung unumgänglich ist?

• Anwendung & Design entwickeln

• Proﬁler / Benchmarks einsetzen

• Flaschenhälse identiﬁzieren

• Ein einfaches und elegantes Design ist oft leichter zu optimieren

Die Weisheit der Bulldogge

Mit kleinen Schritten zum großen Ziel.
Mach es nicht perfekt, mach es gut genug.
Je länger Entscheidungen aufgeschoben werden,
desto mehr Wissen hat man darüber

Der Regenwurm

Vermeide Accidential Complexity.

Vermeide Accidential Complexity

„Simplify essential complexity; diminish
accidental complexity“
Neal Ford

Essential Complexity

• "Essential Complexity" ist die Komplexität, die dem eigentlichen Problem
innewohnt

• Am besten mit "notwendige Komplexität" übersetzt

• Die Komplexität ist durch das Business getrieben und kann nicht ignoriert
werden

Accidential Complexity

• "Accidential Complexity" ist die Komplexität. die durch die technische Lösung
hinzugefügt wird, mit der Absicht, die notwendige Komplexität zu
kontrollieren

• Häuﬁges Problem von eingekauften Lösungen und generischen Frameworks

• Entwickler werden von Komplexität angezogen

• Entwickler wollen komplexe Probleme lösen und lösen damit oft Probleme,
die die Lösung erst eingeführt hat

Accidential Complexity

• JPA

• Rules Engine

• Aspect Oriented Programming

• komplexes Build System

• Stateful Webservices

Vermeide Accidential Complexity

• Verwende Frameworks, die aus
produktivem Code entstanden sind.

• Extrahiere Frameworks aus
bestehendem Code.

• Prüfe, wie viel Prozent des Codes das
tatsächlich vorhandene Problem
adressiert

• Triff keine Entscheidungen aus dem
Elfenbeinturm.

Die Weisheit des Regenwurms

Fokussiere Dich auf das Problem.
Implementiere Lösungen, die Probleme der Domäne lösen, ohne
unnötige Komplexität einzuführen.

Der Kugelﬁsch

Teste, teste, teste.

Unit Tests

„Im Unit Test werden kleinere Programmteile in
Isolation von anderen Programmteilen getestet.“
Frank Westphal

Unit Tests

• Testen eine einzelne Codeeinheit isoliert.

• Die Granularität der Codeeinheit kann von Methoden über Klassen bis hin
zu Komponenten reichen.

• Unit Test-Frameworks

• JUnit

• TestNG

Unit Tests

public class RentalCompanyTest extends TestCase {

private RentalCompany rentalCompany;

public void setUp() {
rentalCompany = new RentalCompany();
}

public void testAddToFleet() {
rentalCompany.addToFleet("vw", new Car("VW", "silber"));
int carCount = rentalCompany.countCarsInFleet();
assertEquals(1, carCount);
}

}

Unit Tests

$ mvn test
...
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running net.schst.tiercode.RentalCompanyTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

Integrationstests

„There is a vast gulf between the process mappers
who model business systems pictorially, and the
programmers who grind out the C++ or Java
or .Net services that support those business
systems. Between the two camps lies a fertile land
of opportunity. It's time to jointly explore it.“
Ward Cunningham

FIT - Framework for Integrated Tests

• Framework für Integrations- und Akzeptanz-Tests

• Der Kunde schreibt die Testfälle in HTML, Word oder Excel

• Bezieht den Kunden in den Entwicklungsprozess ein und fördert agiles
Vorgehen

• Mittlerweile für sehr viele Sprachen verfügbar, auch für Java

Funktionsweise

• Kunde erstellt eine Tabelle mit Eingabe-Parametern und erwarteten
Rückgabe-Werten

• FIT parst die HTML-Tabelle und interpretiert diese als Testfälle

• FIT reicht die Eingabeparameter an den Testcode (Fixture) weiter

• Der Testcode führt den zu testenden Code aus

• FIT holt die das Ergebnis aus dem Testcode

• FIT markiert Abweichungen in der HTML-Tabelle

Webtests mit Selenium

• Dem Kunden sind Unit-Tests egal, wenn die Website nicht funktioniert

• Selenium prüft die Anwendung auf der Ebene, die der Kunde sieht

• Steuert den Browser fern und prüft gegen das erwartete Verhalten

• Funktioniert in allen großen Browsern, auch im IE6

• Tests können über Firefox-Extension aufgezeichnet werden

• Selenium RC ermöglicht Fernsteuerung aus JUnit Tests

Continuous Integration

• Beschreibt den Prozess des regelmäßigen, vollständigen Builds und Testens
einer Anwendung

• Vorteile durch den Einsatz von CI

• Integrations-Probleme werden frühzeitig entdeckt

• Fehler werden nicht verschleppt

• Code Qualität ist über den gesamten Entwicklungsprozess sichtbar

Continuous Integration

SVN Repository CI Server

Die Weisheit des Kugelﬁschs

Better safe than sorry.
Schaffe dir Sicherheitsnetze durch automatisierte Tests auf
verschiedenen Ebenen deiner Applikation.
Integriere regelmäßig und stelle Fehler
frühzeitig fest.

Der Waschbär

Halte deinen Code sauber.

Coding Standards

• Legen fest, wie lang eine Zeile sein darf, wie eingerückt wird, wo geklammert
wird, wo Leerzeichen stehen, wann Großbuchstaben oder Kleinbuchstaben
verwendet werden, wie eine Funktionsdefinition aussehen soll, wie eine
Klassendefinition aussehen soll, wie eine Methodendefinition aussehen soll,
wie und wo Includes verwendet werden sollen, und, und, und, …

• Haben religiöse Sprengkraft

• Sorgen dafür, dass der Code für alle Entwickler lesbar bleibt

• Entwickler haben dadurch Zeit, sich auf das Wesentliche zu fokussieren

Coding Standards in Java

• Checkstyle kann Code gegen verschiedene Regeln prüfen

• Liefert bereits die Regelsets von Sun mit, ist jedoch erweiterbar (hört auf die
Schildkröte)

Verwende Name die ihre Absicht aufdecken

• Namen von Variablen, Methoden oder Klassen, sollten folgende Fragen
beantworten:

• Warum existiert die Variable (Methode oder Klasse)?

• Was macht sie?

• Wie wird sie verwendet?

• int d = 1; // elapsed time in days
int elapsedTimeInDays = 1;

Benennung

• Verwende aussprechbare Namen

• Verwende ein Wort pro Konzept (z.B. fetch, retrieve oder get)

• Vermeide "Nerd Names" in Klassennamen

• ...Helper, ...Manager oder ...Util

• http://www.classnamer.com/

Kommentare

• Gute Kommentare • Schlechte Kommentare

• @todo-Kommentare • Redundante Kommentare

• Informative Kommentare • Postionsmarkierungen

• Javadocs in öffentlichen APIs • Auskommentierter Code

Kommentare sind keine Ausrede für schlechten Code.

DRY - Don‘t Repeat Yourself

„Every piece of knowlege must have a single,
unambiguous, authoritative representation
within a system“
Andrew Hunt and Dave Thomas

DRY - Don‘t Repeat Yourself

• Nichts ist einfacher als Copy & Paste

• „Nummer Eins der Gestanksparade“ in Refactoring von Martin Fowler

• Jede Doppelung von Code leistet Inkonsistenzen und Fehlern Vorschub.

Fehlerhandling

• Verwende Exceptions

• Reichere deine Exceptions mit sinnvollen Informationen an.

• Deﬁnieren Exception-Klassen nach den Bedürfnissen der aufrufenden
Systeme.

• Verwende Exceptions nicht als billige Alternative für goto.

• Gib niemals null zurück.

Die Pfadﬁnder-Regel

„Leave the campground cleaner than you found it“
Robert C. Martin

Die Pfadﬁnder-Regel

• „Don‘t live with Broken Windows“

• Fixe schlechte Designs, falsche Entscheidungen und schlechten Code
sobald du ihn siehst

• Es muss nichts großes sein

• Ändere den Namen einer Variable in einen besseren
Breche eine Funktion auf, die zu groß ist
Eliminiere ein kleine Duplizierung

• Software muss dauerhaft sauber gehalten werden

Die Weisheit des Waschbärs

Dreckiger Code führt zu dreckigem Design.
Lass auch bei Detail-Fragen die gleiche Sorgfalt walten wie bei
großen Design-Entscheidungen.

Fragen?
Vielen Dank für die Aufmerksamkeit.

Bildquellen © iStockphoto.com

Kontakt
holger.rueprich@1und1.de
stephan.schmidt@1und1.de

Die Kunst des Software Design - Java

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Die Kunst des Software Design - Java

Semelhante a Die Kunst des Software Design - Java (20)

Mais de Stephan Schmidt

Mais de Stephan Schmidt (20)

Die Kunst des Software Design - Java