Software Designund Design Patterns

FIO SYSTEMS AG®

Gliederung

•Gutes Design•Typische Designprobleme•Software-Wartung•Schichtenarchitektur•Architektur-Patterns•Übergreifende Patterns•Aufgabenstellung

Was ist gutes Design?

•Einfach•Modular•Gekapselt•Erweiterbar•Stabil•Zweckmäßig

Typische Probleme

•Frontend == Anwendung•Prozeduraler Code•Code Duplication•Architektur, die nicht zum Problem passt•Pattern madness•Design for the unpredictable

Typische Probleme

● Untestbar / keine Unit-Tests● Spaghetti-Code

Folge:● hohe Wartungs- und Pflegekosten● ineffektive Erweiterungen● hohe Fehlerquote● Demotivation● Enge Kopplung

Praxisbeispiel Wartung(stark vereinfacht)

•FIOPORT Vermarktung•Grobkonzept 2003, 35 Seiten•Entwicklungszeit: 1 Jahr, 5 Entwickler•Wartungszeit: 9 Jahre, Wartung und Erweiterung durch

mittlerweile 10 Entwickler

Erstellung vs. Wartung / Pflege

Erstellung

Wartung / Pflege

2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 20130

1

2

3

4

5

6

7

8

9

10

Entwickler

Praxisbeispiel Wartung

Praxisbeispiel Wartung 2(stark vereinfacht)

•FIOPORT Account•Grobkonzept 2003•Entwicklungszeit: 4 Monate, 1 Entwicklerin•Wartungszeit: 9 Jahre, Wartung und Erweiterung durch

mittlerweile 8 Entwickler

Erstellung vs. Wartung / Pflege

Erstellung

Wartung / Pflege

Praxisbeispiel Wartung 2

2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 20130

1

2

3

4

5

6

7

8

Entwickler

Schichtenarchitektur

Schichtenarchitektur

Schichtenarchitektur

Dependency Inversion

•Abhängigkeit Frontend → … → Backend erscheint natürlich

•Dadurch haben Änderungen in niederen Schichten jedoch Auswirkungen auf alles darüber

•Außerdem erschwert eine solche Architektur die Wiederverwendung

Dependency Inversion Principle

Formuliert von Robert C. Martin, 1996:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.B. Abstractions should not depend upon details. Details should depend upon abstractions.

Architektur-Patterns

•Frontend Patterns● MVC● Front Controller● Page Controller● MVP

•BLL-Patterns● Service Layer● Domain Model

•DAL-Patterns● Repository● Data Mapper● Active Record

Frontend-Patterns - MVC

Frontend-Patterns - FC

Frontend-Patterns - FC

Code

Frontend-Patterns - PC

Frontend-Patterns - MVP

Frontend-Patterns - MVP

Code

BLL-Patterns – Service Layer

BLL-Patterns – Service Layer 2

BLL-Patterns – Domain Model

DAL-Patterns – Repository

DAL-Patterns – Data Mapper

DAL-Patterns – Active Record

@products = Product.all@product = Product.find(params[:id])@product = Product.new@product.destroy

Übergreifende Patterns

•Value Object•Data Transfer Object•Factory•Singleton•Observer•Facade•Proxy

Value Object

Data Transfer Object

Factory

Singleton

Observer

Facade

Proxy

Zusammenfassung

•einfaches Design, bereit für geplante Anforderungen•Dependencies planen – Interfaces verwenden•Unit-Tests als Absicherung für Umbauten•Wartungskosten minimieren durch Investition in gute

Architektur-Planung am Projektanfang•Bei bestehendem Code – schrittweise umstellen

Denn: Änderungen werden kommen!

Aufgabe

•Erstellen einer Web-Anwendung für das fiktive Maklerbüro “Alt & Schimmel GmbH” unter Verwendung von mind. 3 Patterns

•Seite für Kunden mit aktuellen Angeboten•Seiten für Händler zur Pflege der Angebote

•Architekturdiagramm•Beliebige Programmiersprache•Vorstellung der Patterns mit Begründung

Quellen, Lesetipps

•Wikipedia (de, en)•Martin Fowler “Patterns of Enterprise Application

Architecture”•Eric Evans “Domain Driven Design”•http://www.oodesign.com• "Design Patterns. Elements of Reusable Object-Oriented

Software" Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides

Fragen?

(Spätere Fragen einfach per E-Mail an die Adresse auf der Veranstaltungswebsite schicken!)

Vielen Dank!

www.fio.de