Begrifflichkeit
Ziel ist es, dem Softwareentwickler einen Wissensfundus an immer wiederkehrenden Problemen und deren Lösung rund um die Softwareentwicklung zur Verfügung zu stellen. Dabei geht es weniger um Technologien, sondern um das entwickeln und dokumentieren stabiler Softwarearchitekturen und von Softwaredesign.
Ursprünge
Standardwerke
- Design Patterns: Elements of Reusable Object-Oriented Software von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides ( GOF , "Gang of Four") ist der Klassiker über Design Patterns
- Pattern-Oriented Software Architecture: A System of Patterns von Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerland und Michael Stal ( POSA ) befaßt sich mit Nutzung von Patterns um komplexere Strukturen zu entwerfen
- Pattern Languages of Program Design 1, Pattern Languages of Program Design 2 enthält ausgewählte Vorträge der ersten und zweiten Konferenz über "Pattern Languages of Program Design" (PLoP oder PLoPD )
- Christoph Alexander Werke befassen sich mit Architektur und Stadtplannung, um die Lebensqualität der Menschen zu
- Notes on the Synthesis of Form
- The Oregon Experiment
- A Pattern Language: Town,Buildings,Construction
- A Timeless Way of Building
Geschichte
- Christoph Alexander
- auf ihn gehen viele Begriffe zurück:
- pattern
- forces
- pattern languages
- er entwickelte in den sechzig und siebzigern mit seinen Mitarbeitern am Center for Environmental Structure in Berkley 250 Muster
- seine zentrale Idee war es, die Architektur auf die Bedürfnisse des Menschen auszurichten ("Windows on Two Sides of Every Room" )
- auf ihn gehen viele Begriffe zurück:
- Ward Cunningham und Kent Beck
- wurden durch die Ideen von Christoph Alexander inspiriert um seine Ideen in der Softwareentwicklung anzuwenden
- 1987 veröffentlichten sie Using Pattern Languages for Object-Oriented Programs eine "pattern language", um das Entwicklen von Benutzerschnittstellen in Smalltalk zu erleichtern
- sie stellten das erste Mustersystem zum Entwurf von Benutzeroberflächen auf:
- Window-per-Task - zu jeder Aufgabe ein eigenes Fenster
- Few-Panes - entwickle für jede Sicht der Aufgabe einen eigenen Bereich in dem Fenster
- Standard-Panes - gestalte die funktionellen Bereiche nach gleichen Grundsätzen
- Nouns-and-Verbs - Handlungsanweisungen ( verbs ) gehören in das Menü und
- Short-Menus
- James Coplien
- 1991 publizierte er das Buch Advanced C++ Programming Styles and Idioms; ein Katalog von C++ Idiomen
- Erich Gamma
- 1991 promovierte Erich Gamma in Zürich über die Verwendung von Mustern in der Softwareentwicklung
- da die Arbeit in Deutsch geschrieben war, erregte die Arbeit außerhalb von Mitteleuropa wenig Aufmerksamkeit
Erich Gamma entwickelte seien Ideen weiter in Amerika
- Erich Gamma, Richard Helm, Ralph Johnson , John Vlissides ( entspricht GoF ), Jim Coplien , Doug Lea
- 1990 - 1992 wird in diversen Workshops ( OOPSLA 91/92 ) ein Katalog von Patterns erarbeitet
- Kent Beck und Grady Booch
- Hillside Group wurde durch die beiden ins Leben gerufen
- GOF
- 1995 wurde das Design Patterns Buch veröffentlicht und alles bis zu diesem Zeitpunkt ist Geschichte
Eigenschaften
- Muster ( nach POSA )
- zielen auf ein in speziellen Entwurfssituationen häufig auftretende Entwurfsproblem und beschreibt eine Lösung für dieses Problem
- dokumentieren bekannte, erprobte Lösungen von Entwurfsproblemen
- identifizieren und spezifizieren Abstraktionen auf einer Ebene oberhalb der von einzelnen Klassen und Objekten und oberhalb der von ganzen Komponenten.
- beschreiben ein gemeinsames Vokabular und Verständig von Entwurfsprinzipien
- sind ein Mittel zur Dokumentation von Softwarearchitekturen
- unterstüzten die Entwicklung von Software mit definierten Eigenschaften
- helfen bei der Entwicklung komplexer, heterogener Softwarearchitekturen
- helfen beim Umgang mit der Komplexität von Softwaresystemen
Definition
- Die Definition zeichen sie alle durch eine Dreigliederung aus
- Dirk Riehle und Heinz Zullighoven: A pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts.
- http://hillside.net/patterns/definition.html: Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occures repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves.
- Christoph Alexander: Each pattern is a three-part rule, which express a relation between a certain context, a problem, and a solution.
- Ein Entwurfsmuster beschreibt eine generische Lösung für ein in einem bestimmten Kontext wiederkehrendes Entwurfsproblem.
Was zeichnet ein Pattern aus ?
Struktur
- Kontext
- Entwurfssituation, in der ein Entwurfsproblem auftritt
- Problem
- Kräfte, die in dem Kontext wirken
- Lösung
- Konfiguration zum Ausgleich der Kräfte
- Struktur mit Komponenten und Beziehungen ( statisch )
- Laufzeitverhalten ( dynamisch )
- Konfiguration zum Ausgleich der Kräfte
Nutzen
- Pattern sollen "useful, useable, and used" sein
- useful: Implementierung von Pattern sollen einen Mehrwert bringen
- useable : die Implementierung eines Pattern sollen aus seiner Beschreibung möglich sein
- used: Pattern definieren sich über ihren Gebrauch ("rule of three")
Anti-Pattern
- während Patterns gerne durch best practice klassifiziert werden, verwendet man gerne den Ausdruck lesson lerned für Anti-Pattern
- Andrew Koenig beschreibt sie 1995 im C++ Report durch: Those that describe a bad solution to a problem which resulted in a bad situation.
- Gerade die Erfahrung über schlechte Lösungen zu wiederkehrenden Problemen, soll helfen, diese "Lösungen" zu vermeiden.
- Die Bücher von Bruce Webster in Pitfalls of Object-Oriented Development und Tom Love in Object Lessons widmen sich dieser Thematik.
Pattern = Design Pattern
- Durch die herausragende Akzeptanz des GoF Buchs Design Patterns, das sich mit objektorientierte Designpattern beschränkt, wurde der Pattern Fokus gerne auf Design Pattern beschränkt.
- Das GoF Buch definiert Design Pattern durch "descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context."
- Daraus resultierte die Annahme, daß es in Design Pattern ausschließliche um objektorientierte Techniken ginge.
- Im nächsten Schritt wurde dann der Begriff Design unterschlagen, so daß Pattern mit Design Pattern gleichgesetzt wurde.
- Pattern zielen aber auf alle Bereiche der Softwareentwicklung, um nur ein paar zu Nennen:
- Analysis Pattern von Martin Fowler
- orgranisatoric pattern
- development organization
- software process
- project planning
- requirement engineering
- software configuration managment
- ...
- Die Autoren von Patterns of Software Architecture, auch bekannt als "Siemes Gang of Five", erweitert die Gleichsetzung von Design Pattern und objektorientiertem Design, in dem sie drei Typen von Pattern einführt.
- Architektur Muster
- drückt eine fundamentalte strukturelle Organisation oder ein Muster für ein Softwaresystem aus
- beschreibt ein System von vordefinierten Teilsystemen, der Verantwortlichkeiten und die Regeln, nach denen sie zusammenarbeiten
- Entwurfmuster
- fokusiert diese oben genannten Teilsysteme, das Zusammenspiel der Komponenten in diesem Softwaresystem
- bescheibt die sich wiederholdende Struktur der in Beziehung stehende Komponenten um ein generelles Design Problem in einem besonderen Kontext zu lösen
- Idiome
- die Implementierung, der soeben genannten Komponenten in einer konkreten Programmiersprache, ist Thema der Idiome
- Der Übergang vom Idiom über das Entwurfsmuster hin zum Architekturmuster kann am Model-View-Controller Pattern schön festgemacht werden
- MVC wurde von Smalltalk Entwickler eingeführt um Benutzerschnittstellen in Smalltalk leichter/besser entwerfen zu können
- in GoF wurde es als Ansammlung von Design Patterns verstanden, um objektoriente Benutzerschnittstellen zu entwerfen
- POSA schließlich fasste es als Architekturpattern auf, das sich aus Design Patterns ( Beobacher- und Kompositmuster ) zusammensetzt
- Der Fokus dieser Dreigliederung geht vom Abstrakten zum Konkreten, von der Makroarchitektur über die Mikroarchitekutr hin zur sprachenspezifischen Techniken.
- Gleichzeitig beschreibt diese Dreigliederung die Konkretisierung des Softwareentwicklungsprozesses vom Grobentwurf über den Entwurf zur Implementierung.
Komponenten eines Patterns
Abgesehen davon, ob das Format eines Pattern der "Alexandrian Form", der "GoF Form", der "Coplien Form" oder der "Portland Form" folgt, sollte in einer Patternbeschreibung folgende Gesichtspunkte erörtert werden.- Name
- ein aussagekräftiger Name oder Ausdruck
- Auch bekannt unter
- eventuelle Angabe von anderen Namen, unter denen das Pattern auch bekannt ist
- Zusammenfassung
- eine kurzer Überblick, um das Pattern zu klassifizieren
- Zweck
- Was will das Pattern erreichen?
- Kontext
- In welchen Umgebungen kann man das Pattern anwenden?
- Interaktionen
- Welche Komponenten gibt es zu Berücksichtigen?
- Wie können diese sich oft widersprechenden Einschränkungen ausgelotet werden?
- Lösung
- Die Beschreibung der Umsetzung des Patterns, seiner Struktur, seiner Komponenten und seiner Kollaborateure.
- Dies wird gerne durch UML - Diagramme unterstüzt.
- Hier sollten auch noch Punkte wie das Laufzeitverhalten, Implementationsspezifische Details und Variationen des Patterns diskutiert werden.
- Beispiel
- keine Abstraktion ohne leicht verdauliches Beispiel
- Konsequenzen
- Welche Konsequenzen ergaben sich aus der Anwendung des Patterns?
- Logische Grundlagen
- Wie schafft es das Pattern die ganzen Kräfte auszuloten um zu einer Lösung zu kommen?
- Verwandte Pattern
- Dies umfaßt Pattern, die gerne in einem ähnlichen Kontext verwendet werden aber auch Pattern, die eine ähnliche Problematik thematisieren.
- Bekannte Verwendungen
- Wo findet sich das Pattern wieder?
- Kurzes Beispiel für das Strategy Pattern
- Name
- Strategy Patterns
- Auch bekannter unter
- Policy
- Zusammenfassung
- kapselt Alogrithmen als Objekt um sie Mittels Delegation zur Laufzeit austauschen zu können
- Zweck
- Client ( Applikation ) kann zur Laufzeit entscheiden, wie ( nach welcher Strategie ) seine Anfrage bearbeitet wird
- Kontext
- Mehrere Variation eines Algorithmus sollen dem Klienten transparent zur Verfügng gestellt werden
- Interaktion
- Um die Transparenz zu gewährleisten, verberge die Strategien hinter einem Interface
- dem Klienten kann im Konstruktor oder auch zur Laufzeit ein neue Strategie übergeben werden
- Lösung
- führe ein Interface ein, vom dem du die ganzen Strategien ableitest
- stelle jedem Klienten über Delegation die entsprechende Strategie zur Verfügung
- Beispiel
- std::string in C++ setzte sich aus drei Eigenschaften zusammen, die durch einen einfachen typedef bekannt gemacht werden
- char: elementar Datentyp
- char_traits: Verhaltseigenschaften ( Sortierung der Charaktertypen, ... )
- allocator: Speichereigenschaften
typedef basic_string < char,class T= char_traits<char>,class A = allocator<char> > string
- Find Minima von Bruce Eckel
- std::string in C++ setzte sich aus drei Eigenschaften zusammen, die durch einen einfachen typedef bekannt gemacht werden
- Konsequenzen
- Alternative zur Unterklassenbildung ( vgl. Templatemethode )
- keine Bedingungen
- Klienten müssen von den Strategien wissen
- zusätzliche Indirektion
- erhöhte Anzahl an Objekten
- Logische Grundlagen
- durch das kapseln der Algorithmen in Objekte und die Delegation der Algorithmenaufrufe an die Objekte ist diese Flexibilität möglich
- Verwandte Pattern
- Template Methode
- kapsle die Variabilität nicht in Objekte sondern in virtuelle Funktionen, die dann entsprechend überladen werden müssen
- Traits
- verwende Untertypen um ein komplexeren Typ zusammenzubauen ( vgl. std::string )
- der Unterschied in dem Strategy Pattern und Traits besteht weniger in der Architektur sondern in der Intention des Musters Stratgie Pattern kapseln Verhalten ( Algorithmen ) hingegen Traits Typen
- der Unterschied in dem Strategy Pattern und Traits besteht weniger in der Architektur sondern in der Intention des Musters
- verwende Untertypen um ein komplexeren Typ zusammenzubauen ( vgl. std::string )
- Template Methode
- Bekannte Verwendungen
- Container in C++
- Name
Qualität der Pattern
Doug Lea nennt in seinem Artikel Christoph Alexander: an Introduction to Object-Oriented Designers" folgende Qualitätsmerkmale der Pattern- Encapsulation and Abstraction
- jedes Pattern kapselt das Wissen über das Problem und deren Lösung in einem bestimmten Kontext
- gleichzeitig stelle es eine Abstraktion über Kontextwissen und Kontextfahrung dar
- Openess and Variability
- Pattern sind offen für Erweiterung und Parametrisierung um ein größeres Problem zu lösen
- darüber hinaus unterstützen Muster Variablität der Implementierung
- Generativity and Composability
- Pattern erzeugen einen Kontext für andere Pattern, der sich mit Pattern allgemeiner oder konkreter Struktur gestalten lässt
- Equilibrium
- bei dem durch ein Pattern erreichte Lösung soll der Nutzen und die Einschränkungen in einem ausgewogenen Verhältnis zueinander stehen
Intellektuelle Anspruch
"The human element of patterns is what chiefly contributes to their variability and adaptability, and usually requires a greater degree of creativity in their application and combination."- James Coplien verwendet in diesem Zusammenhang das Bild eines Schneider, der zwar ein Schnitt besitzt, diesen aber an den Kunden anpassen muß.
Abgrenzung
Algorithmen
- Viele der bisher genannten Punkte lassen sich auch auf Algorithmen und Datenstrukturen anwenden.
- Algorithmen fokussieren aber viel feinkörnigere Probleme.
- Design Pattern kapseln gerne Algorithmen.
- Während die Intention bei Algorithmen oft auf Optimierung im Ressourcen- und Zeitbereich liegt, thematisieren Pattern gerne allgemeine Architekurbelange mit weitreichenden Konsequenzen.
Frameworks
Framework (GoF): A framework is a set of cooperating classes that make up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes a framework to a particular application by subclassing and composing instances of framework classes.- Ein Framework bietet also eine Infrastruktur, nicht eine komplete Applikation, die an expliziten Stellen an die eigenen Bedürfnisse angepaßt werden kann.
- Diese Erweiterbarkeitstellen, auch "plug points" oder "hot spots" werden gerne durch callback, Polymorphismus oder Delegation zur Verfügung gestellt.
- Eine Framework kapselt die Design Entscheidungen einer Domäne und fördern somit die Design Wiederverwendung über die Code Wiederverwendung.
- Der klassische Unterschied zwischen einem Framework und einer Bibliothek ist, das das Framework den Kontrollfluß invertiert.
- Während der Client bei einer Bibliothek Funktionalität dieser aufruft, passt der Frameworknutzer dasselbige an seine Anforderungen an.
- Dies Verhalten wird durch das Hollywoodprinzip "Dont't call us, we'll call you." charakterisiert.
- Frameworks stellen die Realisierung von einer oder mehreren Software Pattern Lösungen dar; Pattern hingegen sind Anweisungen, wie diese Lösungen implemtiert werden sollten.
- Abschliessend noch die Charakterisierung durch GoF:
- Design patterns are more abstract than frameworks.
- Design patterns are smaller architectural element than frameworks.
- Design patterns are less specialized then frameworks.
Systematik
oder Wie finde ich das richtige Pattern zu meinem Problem?- Einen recht pragmatischen Ansatz (außer Konkurrenz) verfolgt Who ya gonna call?.
Pattern Language
James Coplien definiert Pattern Language als "A pattern language defines a collection of patterns and the rules to combine them into an architectural style. Pattern languages describe software frameworks or families of releated systems."- Eine Pattern languages wird auch gerne als Patternvocabular und deren Grammatik beschrieben, mit der man alle gültige Sätze konstruieren kann.
- Das Patternvocabular und deren Regeln erlauben es idealerweise, alle Architekturprobleme innerhalb dieser Domäne zu lösen.
- Das Wissen zu Lösung der Sturkturprobleme der speziellen Domäne ist in der Pattern Language gekapselt.
- Pattern Languages führen Systemanalytiker, Architekten, Designer und Codierer um ein arbeitsfähiges System zu erzeugen, das die verschiedenen auftretende Pläne beim Entwickeln des Gesamtsystems löst.
Muster System
- POSA
- Ein Mustersystem für Softwareentwickler ist eine Sammlung von Mustern für Softwarearchitektur, zusammen mit Richtlinien für ihre Implementierung, ihre Kombination und ihren praktischen Einsatz in der Softwareentwicklung.
Des wesentliche Unterschied zwischen einer Pattern Language und einem Mustersystem besteht darin, das eine Patternlanguage idealerweise versucht eine Domäne vollständig abzudecken, während ein Mustersystem die Softwareentwicklung thematisiert.- Mustersystem sollen folgenden Anforderungen genügen
- Mustersystem sollten ein genügend große Anzahl von Mustern enthalten.
- Alle Muster eines Mustersystems sollten auf einheitliche Art und Weise beschrieben werden.
- Ein Mustersystem sollte die vielfältigen Beziehungen zwischen den Mustern aufzeigen.
- Ein Mustersystem sollte seine Bestandteile geeignet anordnen.
- Ein Mustersystem sollte die Konstruktion eines Softwaresystems unterstüzten.
- Ein Mustersystem sollte seine eigene Weiterentwicklung unterstützen.
GoF
- Das wohl bekannteste Mustersystem stammt von GoF.
- Sie gruppieren die Muster nach zwei Kriterien
- welche Aufgabe haben die Muster
- Erzeugungsmuster: unterstüzten die Objekterzeugung
- Strukturmuster: fassen Klassen und Objekte zu größeren Strukturen zusammen
- Verhaltensmuster: beschreiben die Interaktion zwischen Objekten und deren Kontrollflüsse
- welchen Gültigkeitsbereich haben die Muster; d.h. beziehen sich primär auf Klassen oder Objekte
- Klassenmuster statisch
- legen ihre Struktur durch Vererbung fest
- sind zur Übersetzungszeit vorgegeben
- Objektmuster dynamisch
- legen ihre Struktur durch Aggregation und Assoziation fest
- können zur Laufzeit konfiguriert werden
- Klassenmuster
- welche Aufgabe haben die Muster
- Somit ergibt sich folgende Strukturierung
Gültigkeitsbereich Erzeugungsmuster Strukturmuster Verhaltensmuster Klassenmuster Fabrikmethode Adapter Interpreter
SchablonenmethodeObjektmuster Abstrakte Fabrik
Erbauer
Prototyp
EinzelstückAdapter
Brücke
Kompositum
Dekorierer
Fassade
Fliegengewicht
StellvertreterZuständigkeitkette
Kommando
Iterator
Vermittler
Memento
Beobachter
Zustand
Strategie
Besucher - die Autoren stellen zwei Sichten auf das Mustersystem um das gesuchte Muster zu finden
- Welcher Aspekt variiert bei dem Muster?
Aufgabe Entwurfsmuster Variierende Aspekte Erzeugungsmuster Abstrake Fabrik Familie von Produktobjekten Erbauer Erzeugung eines zusammengesetzten Objekts Fabrikmethode Unterklasse, von der ein Objekt erzeugt wird Protoype Klasse des zu erzeugeenden Objekts Singleton Das einzige Exemplar seiner Klasse Strukturmuster Adapter Schnittstelle eines Objekts Brücke Implementierung eines Objekts Dekorierer Zuständigkeit eines Objekts ohne neue Unterklasse Fassade Schnittstelle zu einem Subsystem Fliegengewicht Speicherkosten eines Objekts Kompositum Struktur und Zusammensetzung eins Objekts Proxy Zugriff auf eine Objekt sowie seinen Ort Verhaltensmuster Befehl Zeitpunkt und Art der Ausführung einer Anfrage Beobachter Anzahl der von einem Objekt abhängigen Objekte sowie die Art,
in der die Objekte aktualisiert werdenBesucher Operationen, die auf Objekte ohne Änderung ihrer Klasse angewendet werden können Interpreter Grammatik und Interpretierung einer Sprache Iterator Zugriff und Traversierung der Elemente eines Aggregats Memento Umfang und Zeitpunkt der Speicherung primitver Informationen eines Objekts außerhalb von ihm Schablonenmethode Schritte eines Algorithmus Strategie Ein Algorithmus Vermittler Zusammenarbeitende Objekte sowie die Art ihrer Zusammenarbeit Zustand Zustände eines Objekts Zuständigkeitskette Objekte, die eine Anfrage bearbeiten können - In welcher Beziehung stehen die Muster zueinander?
- die häufigst auftretenden Muster sind gelb ausgezeichnet
- folgende Graphik veranschaulicht die Beziehungen zwischen den Mustern
- die häufigst auftretenden Muster sind gelb ausgezeichnet
- Welcher Aspekt variiert bei dem Muster?
- Sie gruppieren die Muster nach zwei Kriterien
- Das GoF Mustersystem besitzt nach meiner Ansicht ein paar Nachteile, wenn man versucht, das passende Muster zu seinem Problem zu finden:
- die Klassifizierung ist zu grob
- die Unterscheidung Objektmuster, Klassenmuster trägt wenig zur Entscheidung bei, denn:
class Shape
virutal Shape* clone() =0 ;
};
class Circle: public Shape{
Shape* clone() { return new Circle; }
}
class Ellipse: public Shape{
Shape* clone() { return new Ellipse; }
}
....
Circle& cir;
Ellipse& ell;
Shape* cirShape= cir.clone();
Shape* ellShape= ell.clone();
... - zwar ist die Fabrikmethode
clone()
ein Klassenmuster, eingesetzt wird sie aber über Delegation an Objekte
POSA
- ein deutlich praktikableres Mustersystem enthält POSA, wobei die neu hinzugekommenen Muster aus dem gleichnamigen Buch stammen
- POSA verwenden eine Musterkategoriensichtund eine Problemkategoriensicht, um Struktur in dem Musterklassifizierung zu bringen
- die Musterkategoriensicht beschreibt die Sicht vom Groben zum Konkreten, vom Grobentwurf über den Feinentwurf zur Implementierng hin
- die Problemkategoriensichtthematisiert das grundlegende Problem und seine Lösung nach folgenden Kategorien
- vom Chaos zum Struktur: geeignete Zerlegung einer Gesamtaufgabe in Teilaufgaben
- Verteilte System: Infrastruktur für Systeme, deren Komponenten in verschiedenen Prozessen oder Adreßräumen liegen
- Interaktive Systeme: System mit Mensch-Computer-Interaktion
- Adaptierbare Systeme: Infrastruktur, um eine Anwendung erweiterbar und an neue Anforderung anpaßbar zu gestalten
- Strukturelle Zerlegung: Zerlegung von Subsystemen und komplexe Komponenten in geeignet miteinander kooperierende Komponenten
- Organisation und Arbeit: Zusammenarbeit von mehreren Komponenten um gemeinsam eine komplexe Dientleisung anzubieten
- Zugriffskontrolle: Zugriff auf Dienste und Komponenten schützen und konrollieren
- Management: homogene Menge von Objekten, Diensten und Komponenten in ihrer Gesamtheit behandeln
- Kommunikation: Kommunikation zwischen Komponenten zu organisieren
- Ressourcenverwaltung: helfen bei der Verwaltung gemeinsam genutzter Komponenten und Objekte
- kursiv geschriebene Pattern bezeichnen die GoF Patterns in ihrer geläufigeren, englischsprachigen Bezeichnung
Problemkategorie Architekturmuster Entwurfsmuster Idiome Vom Chaos zur Struktur LayersPattern
Pipes-and-Filters
BlackboardInterpreter Verteilte Systeme Broker
Pipes-and-Filters
MicrokernelInteraktive Systeme Model-View-Controller
Presentation-Abstraction-ControlAdaptierbare Systeme Microkernel
ReflectionErzeugung Abstract-Factory
Prototyp
BuilderSingleton
Factory-MethodStrukturelle Zerlegung Whole-Part
CompositeOrganisation von Arbeit Master-Slave
Chain-of-Responsibility
Command
MediatorZugriffskontrolle Proxy
Facade
IteratorVariation von Diensten Bridge
Strategy
StateTemplate-Method Erweiterung von Dienstleistungen Decorator
VisitorManagment Command-Processor
View-Handler
MementoAdaption Adapter Kommunikation Publisher-Subscriber
Forward-Receiver
Client-Dispatcher-ServerRessourcenverwaltung Flyweight Counted-Pointer - folgenden idealisierten Weg empfehlen POSA, um in einer konkreten Situation ein geeignetes Muster auszuwählen
- Spezifikation des Problems
- Auswahl der Musterkategorie, die der Entwurfsaktivität entspricht
- Auswahl der Problemkategorie
- Vergleich der Problembeschreibungen
- Abwägen der Vor- und Nachteile
- Auswahl der passende Variante
- Gehe eventuell zurück zur Auswahl der Problemkategorie
Anwendung
- Schon Christoph Alexander betonte, daß eine Architektur und die darin angewendeten Pattern nicht entworfen wird, sondern daß sich die Architektur sukzessive durch Anwendung von Pattern entwickelt ("Piecemeal Growth").
Pattern schreiben
- Der Prozeß, Pattern zu entdecken um sie zu dokumentieren wird "pattern mining" oder auch "reverse-architecting" genannt.
- In POSA werden folgende Kriterien genannt, die man beim Entwickeln von Patterns beachten sollte:
- Fokus auf Praktikabilität
- Ablehnung von Urheberschaft
- Öffentlicher Review
- Vorstellung und Diskussion in Workshops
- Sorgfältiges Editiern und insbesondere Berücksichtigen der öffentlichen Diskussion durch den Autor
Abschließende Bemerkungen
- Brad Appleton:
- "So while the ability to codify patterns as generic software components may be important, even more important is the knowledgte of how/when to apply and combine patterns, in conjunction with the ability to use a shared vocubulary of patterns names ... ."
- Pattern verkörpern konzentrierte Erfahrungen in der Softwareentwicklung, die man sowohl positv "best practices" als auch negativ "lesson learned" gewonnen hat.
Weiterlesen...