Software Design und Design Patterns FIO SYSTEMS AG ®
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 = [email protected]
Ü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