Inhalt
- Arten von Mustern und Patterns
- Allgemeine Design Patterns
- Java EE Patterns
- Links auf weiterführende Informationen
Arten von Mustern und Patterns
- Allgemeine Definitionen
- Muster (Patterns) beschreiben häufig auftretende Entwurfsprobleme und dazu universell verwendbare generische Lösungsschemen.
- Architekturmuster beziehen sich auf die Architektur von Softwaresystemen.
- Entwurfsmuster (Design Patterns) sind weniger stark abstrahiert und beziehen sich eher auf die Softwarekodierung.
Die bekanntesten Design Patterns sind von GoF beschrieben
(Gang of Four: Gamma, Helm, Johnson und Vlissides).
- Arten von Architekturmustern
- Struktur (Layer, Pipes and Filters, Blackboard)
- Verteilte Systeme (Broker, Microkernel, Pipes and Filters)
- Interaktive Systeme (MVC / Model-View-Controller, Presentation-Abstraction-Control)
- Adaptierbare Systeme (Microkernel, Reflection)
- Ereignisverarbeitung (Proactor, Reactor)
- Synchronisation (Object Synchronizer)
- Arten von Entwurfsmustern (Design Patterns)
- Erzeuger-Muster (Prozess der Objekterzeugung: Abstract Factory, Builder, Factory Method, Prototype, Singleton)
- Struktur-Muster (Zusammenbau von Klassen und Objekten: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy)
- Verhaltens-Muster (Algorithmen sowie Aufgabenteilung zwischen Klassen: Iterator, Mediator, Observer, State, Strategy, Template Method, Visitor)
- Im Folgenden werden einige Design Patterns erläutert.
Dabei wird teilweise Java-spezifische Terminologie verwendet.
Allgemeine Design Patterns
- Component
- Der Begriff 'Component' bzw. 'Komponente' wird nicht immer einheitlich definiert.
Eine mögliche Definition ist:
- - Bietet vertraglich definierte Schnittstellen an (z.B. per Java-Interface)
- Verwendet ausschließlich wohldefinierte explizite Abhängigkeiten
- Ist oft für verschiedene Anwendungsfälle konfigurierbar und wiederverwendbar
- Ist oft einzeln deploybar
- Composite
- Das Design Pattern Composite erlaubt das Zusammenfügen (Komposition) von Objekten, zum Beispiel zu Baumstrukturen.
- Anwendungsbeispiele: Menüs mit Untermenüs, hierarchische Verzeichnisstrukturen, mechanisch zusammengesetzte Bauteile mit Unterbaugruppen.
- Benötigt werden die zwei Bestandteile:
- Eine (oft abstrakte) Basisklasse (oft als Component bezeichnet),
die sowohl zusammengesetzte als auch elementare Objekte repräsentiert
- Alle elementaren Objekte sind von dieser Basisklasse abgeleitet
- Es gibt mindestens eine Container-Klasse, die ebenfalls von dieser Basisklasse abgeleitet ist
und die eine Menge der elementaren Objekte aufnehmen kann
- Delegate
- Bei der Delegation verwendet eine Klasse die Dienste von Objekten, von denen sie nicht abgeleitet ist,
obwohl diese Dienste eigentlich inhaltlich zur Klasse gehören und dort vermutet werden.
Die explizite Übertragung der Aufgaben per Delegate macht den Code verständlicher.
Sinn macht dies zum Beispiel, wenn identische Funktionalität in verschiedenen Klassen benötigt wird,
die nicht in einer gemeinsamen Vererbungslinie stehen.
- Folgende Merkmale beinhaltet ein Delegate typischerweise:
- Der Name der Delegate-Klasse endet oft mit der Silbe Delegate
- Die Clients halten eine Referenz auf das Delegate-Objekt, um dessen Methoden aufrufen zu können
- Falls das Delegate-Objekt auch Methoden des Clients aufrufen soll (Callback),
sollte ein Delegator-Interface definiert und von den Clients implementiert werden
und eine Referenz auf den Client dem Delegate-Konstruktor übergeben werden
- Factory
- Eine Factory ist ein Hilfsmittel zur Erzeugung von Produkten und Objekten, unabhängig von konkreten Klassen.
Sie wird verwendet, wenn die Instanziierung nur über den new()-Operator nicht möglich oder nicht sinnvoll ist,
zum Beispiel wenn das Objekt schwierig zu konstruieren ist oder vorher konfiguriert werden muss.
- Beispiele für Einsatzbereiche:
- Die zur Generierung des Objekts verwendete Klasse ist erst zur Laufzeit bekannt
- Das Objekt muss aus einer Datenbank geladen werden (oder: aus Datei, über Netzwerkverbindung)
- Die drei wichtigsten Varianten einer Factory sind: Factory-Methode, Factory-Klasse und abstrakte Factory.
- Factory-Methode:
Factory-Methoden sind statische Methoden zur Erzeugung von Objekten des eigenen Klassentyps.
Ein Singleton kann zum Beispiel als Spezialfall einer Klasse mit einer Factory-Methode angesehen werden.
- Factory-Klasse:
Eine Factory-Klasse stellt eine Erweiterung des Konzepts der Factory-Methode dar.
Hier gibt es zur Instanziierung nicht nur Methoden innerhalb der eigenen Klasse,
sondern dafür gibt es eine eigene Klasse.
Dadurch kann die Factory zum Beispiel leichter ausgetauscht werden.
- Abstrakte Factory:
Die abstrakte Factory ist die aufwändigste Variante und wird manchmal auch als Toolkit bezeichnet (z.B. java.awt.Toolkit).
Zwei wichtige Merkmale der abstrakten Factory sind:
- Es wird nicht nur ein Objekttyp (Produkt), sondern viele verschiedene erzeugt
- Die gesamte Factory (für alle Objekttypen) ist leicht austauschbar
Beispielsweise bei einem Toolkit für die Erzeugung von Dialogelementen (Widgets) für GUIs
wird nicht nur ein Objekt, sondern werden viele verschiedene Objekte (GUI-Dialogelemente) erzeugt
und die Factory soll leicht austauschbar sein, um auf verschiedenen Plattformen lauffähig zu sein
(was dann natürlich konkrete Factories z.B. für Windows, X-Window, Macintosh, Palm, Smartphone voraussetzt).
- Immutable
- Immutable Objekte können nach ihrer Instanziierung nicht mehr verändert werden.
Dadurch können sie gefahrlos mehrfach referenziert werden und erfordern keinen Synchronisationsaufwand beim Multithreading.
- Beispiele im Java-Bereich: String-Klasse, Wrapper-Klassen.
- Wichtige Designmerkmale einer Immutable-Klasse:
- Alle Membervariablen sind privat
- Schreibende Zugriffe auf Membervariablen ausschließlich im Konstruktor oder in Initialisierern
- Interface
- Ein Interface trennt die Beschreibung der Funktionalität einer Klasse von ihrer Implementierung.
Ein Interface ist eine spezielle Klassendeklaration (ähnlich abstrakten Klassen)
und kann nur Methoden ohne Implementierung (abstract) sowie Konstanten (static final) beinhalten.
Zum Beispiel in Java gibt es (anders als in C++) keine Mehrfachvererbung und keine Funktionszeiger.
Beide Funktionalitäten werden per Interface erreicht.
Besonders in Java ist ein Interface ein fundamentales und sehr leistungsfähiges Sprachelement.
- Iterator
- Der Iterator ist ein Objekt, welches es ermöglicht, komfortabel die Elemente eines Collection-Objekts zu durchlaufen.
- Übliche Methoden eines Iterators sind: hasNext() und next().
-
Model-View-Controller (MVC)
- Ähnlich Observer-Muster.
Zur Entkopplung von Fachobjekten und deren Darstellung.
Übliche Methoden: show(), updateModel(), updateView().
- - Model: Fachklasse, Applikationsschicht
- - View: Darstellung, Präsentationsschicht (meistens visuelles GUI, inklusive Bedienelemente), auch mehrere Views gleichzeitig möglich
- - Controller: optional kann zu jedem View jeweils ein Controller die Entgegennahme und Koordination von Benutzerinteraktionen steuern
-
Observer
- Ein Observer baut eine Beziehung zwischen einem Subjekt und seinen Beobachtern auf,
so dass Zustandsänderungen mitgeteilt werden.
- Beispiele: Die GUI-Darstellung muss Datenänderungen folgen, Dialogelemente müssen Anwenderaktionen mitteilen.
- Observer besteht aus den Teilen:
- Das Interface Observer definiert die Methode update(), die bei Zustandsänderungen aufgerufen wird
- Die Klasse Subject definiert Methoden zur Registrierung und Deregistrierung von Observern (z.B. attach() und detach())
und ruft bei Zustandsänderungen die update()-Methoden der registrierten Observer auf
- Konkrete Subjekte werden von Subject abgeleitet und melden ihre Zustandsänderungen über die Methode fireUpdate()
- Konkrete Beobachter implementieren das Interface Observer, registriert sich bei den gewünschten Subjekten
und werden über update() über Zustandsänderungen der Subjekte informiert
- In Java ist das Observer Design Pattern sehr verbreitet, meistens in einer zum "Delegation Based Event Handling" erweiterten Version:
Die Beobachter werden als Listener bezeichnet, die von verschiedenen Typen sein können und mehrere update()-Varianten für verschiedene Ereignisse enthalten können.
Um die Ereignisse besser bearbeiten zu können, werden den update()-Methoden Listener-spezifische Ereignisobjekte mit übergeben.
- Singleton
- Von einer Singleton-Klasse kann nur ein einziges Objekt erzeugt werden,
welches beim ersten Zugriff automatisch instanziiert wird.
So entsteht eine globale Zugriffsmöglichkeit auf dieses Objekt.
- Beispiele für Singletons: Windows-Fenstermanager, Drucker-Spooler, Firmenstamm in einem Abrechnungssystem.
- Wichtige Designmerkmale einer Singleton-Klasse (in Java-Terminologie ausgedrückt):
- Statische Membervariable ihres eigenen Typs, in dem die einzige Instanz gespeichert wird
- Statische Methode getInstance() für den Zugriff
- Privaten parameterlosen Konstruktor, so dass andere Klassen nicht mit new() eine Instanz erzeugen können
- Visitor
- Mit dem Design Pattern Visitor können Datenstrukturen (wie z.B. Composite) mit Verarbeitungsalgorithmen versehen werden.
- Beispiel: In hierarchische Dateiverzeichnisstrukturen die Summe aller Dateigrößen ermitteln oder Dateien eines bestimmten Typs zu bearbeiten.
- Es besteht aus den Teilen:
- Interface Visitor zur Definition der Methoden (oft mit dem Präfix visit),
die beim Durchlaufen der Datenstruktur aufgerufen werden
- Methode accept() in der Basisklasse der Datenstruktur (z.B. Component),
der ein Visitor-Objekt übergeben wird und die die zur Klasse passende Methode des Visitors aufruft
(accept() kann in den abgeleiteten Komponentenklassen überlagert werden)
- Konkreter Visitor zu jeder zu implementierenden Operation
- Um die Funktionalität eines bestimmten Visitors zu benutzen, wird dieser instanziiert und an das Hauptobjekt der Datenstruktur übergeben
Java EE Patterns
Eine Java-EE-Webanwendungen kann typischerweise etwa folgenden vereinfachten Aufbau haben:
Client
|
|HTTP
............................. | .............................
. | Web Container.
. Front Controller .
. | .
. Business Delegate .
............................. | .............................
|RMI-IIOP
............................. | .............................
. | EJB Container.
. Session Facade (Session EJB) .
. ____________________|____________________ .
. | | | | .
. Entity EJB Entity EJB Entity EJB MDB .
. | | | | .
........ | ........... | ........... | ........... | ........
| | | |
SQL-Datenbank ERP, Legacy JMS
Für solche und ähnliche Webanwendungen auf Java EE Application Servern hat Sun in seinen
BluePrints folgende 15
Core J2EE Patterns
definiert:
↑ Client Tier
.........................................................................................
Intercepting Filter Composite View ↓ Presentation Tier
(Decorator-Servlet-Filter) (Frames, Tables, Tiles)
| ↑
| |
|--- Front Controller ---|
| (z.B. Struts) |
| | |
| V |
|--- View Helper ---|
| (CustomTags, TO) |
| | |
| | |
Dispatcher View | Service To Worker
(Navigation) | (Ausführungsfluss)
| | |
| | |
V V V
Business Delegate -----> Service Locator
(Entkoppl.-Adapter) (JNDI-Lookup-Cache)
| ↑ Presentation Tier
.............................. | ........................................................
V ↓ Business Tier
┌-----------------> Session Facade -----> Service Locator
| (Session-EJB) (JNDI-Lookup-Cache)
| | | | |
| | | | |
| V | | |
| Transfer Object Assembler | | └--> Value List Handler
| (zusammengesetzte TOs) | | (It/Scr in Ergebnislisten) --┐
| | | | | | |
| | | ┌-----┘ | | |
| | | | ┌----|--------┘ |
| | V V V | |
| | Transfer Object └----> Composite Entity |
| | (Daten-JavaBean) <-------- (mehrere DB-Tabellen zus.) |
| | ↑ | |
| └------------------┐ | | | ↑ Business Tier
. | ...................... | | ................. | .................. | ................
V | | V |
Service Activator | └---------- Data Access Object <-┘ Integrat. Tier
(asynchron, MDB/JMS) └------------> (Zugriff auf Daten/Ress.)
.........................................................................................
↓ EIS Tier (JMS, Datenbanken, ERP, Legacy)
-
Intercepting Filter
- Preprocessing und Postprocessing von Anfragen vom und Antworten zum Webclient (z.B. Webbrowser, Smartphone).
Dies kann zum Beispiel beinhalten:
Authentifizierung, Sessionvalidierung, Logging, Dekodierung, XML-Parsing, FOP für PDF.
- Flexible durch deklarative Konfiguration leicht austauschbare 'Pluggable Filter' in einer 'Filter Chain',
üblicherweise mit Servlet-Filtern.
- Das Intercepting Filter kann als GoF-Decorator-Pattern realisiert sein.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/InterceptingFilter.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html.
-
Composite View
- Das im Webbrowser gezeigte Fenster ist häufig aus Unterfenstern zusammengesetzt.
- Um flexible einzelne Unterfenster ändern oder austauschen zu können,
sollten sie möglichst entkoppelt sein.
Verschiedene Technologien und Strategien kommen in Frage:
Frames, Portlets, Struts-Tiles, HTML-Tables, JSP page Views, Servlet Views,
JavaBean View Management, Standard Tag Views, Custom Tag Views, Transformer Views.
- Der Composite View basiert auf dem GoF-Composite-Pattern.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/CompositeView.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeView.html.
-
Front Controller
- Controller für zentralisiertes konfigurierbares Request-Management.
- Kann mit verschiedenen Technologien und Strategien realisiert werden.
- Häufig wird hierfür das Struts-Framework eingesetzt.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/FrontController.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html.
-
View Helper
- Business Data Adapter zur Aufbereitung der Geschäftsdaten für die Anzeige,
zum Beispiel Zwischenspeicherung, Umwandlung zu Strings, Formatierung.
- Realisierung zum Beispiel in
Custom Tags
oder JavaBeans (z.B. TO, Transfer Object, VO, Value Object, ValueBean).
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/ViewHelper.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html.
-
Dispatcher View
- Zentrale Navigationskontrolle zur Auswahl der nächsten Webseite.
- Kann vom Struts-Framework mit abgedeckt werden.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/DispatcherView.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html.
-
S2W, Service To Worker
- Steuert Ausführungsfluss und Zugriff auf Geschäftsdaten.
- Ähnlich wie das Dispatcher-View-Pattern, aber weitergehendere Kontrollmöglichkeiten.
Navigation über GoF-Command-Pattern anhand von Kommando-Mappings oder Kommando-Interpretation.
- Kann vom Struts-Framework mit abgedeckt werden.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/ServiceToWorker.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceToWorker.html.
-
BD, Business Delegate
- Entkopplung der Presentation Tier (Präsentationsschicht) und der Business Tier (Geschäftslogik).
- Vorteile:
- Die Präsentationsschicht kann leichter ausgetauscht werden, z.B. für verschiedene Clients (Fat Client, Webbrowser, PDA, Smartphone)
- Adapter für eine für den Presentation Tier geeignetere Schnittstelle (optimierte Methoden)
- Internas des Business Tiers werden verborgen (z.B. JNDI-Lookup, EJB-Home-Interface, RMI)
- Thread-Synchronisierung für single-threaded Zugriff auf Session EJB
- Technische Exceptions können abgefangen und in benutzerfreundlichere umgewandelt werden
- Zentrale Schnittstelle erleichtert Caching
- Der Business Delegate läuft typischerweise im Web Container,
wird aber trotzdem häufig dem Business Tier zugerechnet,
der ansonsten überwiegend im EJB Container läuft.
- Ein Business Delegate wird normalerweise entweder entsprechend dem GoF-Proxy-Pattern
oder entsprechend dem GoF-Adapter-Pattern umgesetzt.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/BusinessDelegate.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html.
-
SF, Session Facade
- Ähnlich dem Business Delegate Entkopplung der Presentation Tier (Präsentationsschicht) und der Business Tier (Geschäftslogik),
aber mit anderer Technologie und anderen Schwerpunkten:
- - Als Session EJB für Clientanbindung zuständig
- Aufruf der internen Entity EJB (sollen nicht von Clients direkt aufgerufen werden)
- Zusammenfassung von Methodenaufrufen
- Realisierung von Geschäftsprozessen
- Transaktionssteuerung (Transaction Demarcation)
- Zentrales Sicherheitsmanagement, Autorisierung, Caching
- Session Facaden in Form einer Stateless Session Bean werden manchmal auch als 'Service Component'
und im Falle einer Stateful Session Bean als 'Session Component' bezeichnet.
- Die Session Facade basiert auf dem GoF-Facade-Pattern.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/SessionFacade.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html.
-
Service Locator
- Singleton für Abstraktion und Caching der InitialContext-Erzeugung und der JNDI-Lookups
(insbesondere EJBHome-Objekte und JMS-ConnectionFactory-Objekte).
Kann auch 'Narrowing' übernehmen.
Der Service Locator (manchmal auch EJBHome Factory genannt) führt zu Vereinfachungen und Performancegewinnen.
Eine mögliche Realisierung finden Sie unter
jee-jndi.htm#ServiceLocator.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/ServiceLocator.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html.
-
Value List Handler
- Iterator für und Scrollen in Ergebnislisten (z.B. Suchergebnissen, event. als Ergebnis von Entity-EJB-Finder-Methoden).
Kann zum Beispiel in Stateful Session EJB realisiert werden.
- Der Value List Handler verwendet das GoF-Iterator-Pattern.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/ValueListHandler.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html.
-
TOA, Transfer Object Assembler
- Zusammenfassung mehrerer Transfer Objecte (TO, VO, Value Object, ValueBean) zu einem Composite Transfer Object.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/TransferObjectAssembler.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObjectAssembler.html.
-
TO, Transfer Object
- Serialisierbare JavaBean-Objekte zum Datenaustausch (VO, Value Object, ValueBean).
Enthalten die Daten als Attribute.
Attributzugriff entweder direkt oder über Getter/Setter-Methoden.
Kann als Immutable implementiert sein.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/TransferObject.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html.
-
CE, Composite Entity
- Zusammenfassung mehrerer in Beziehung zueinander stehenden fine-grained Entity EJBs zu einem coarse-grained Persistenzobjekt.
Kann mit CMR (Container Managed Relations) vereinfacht werden.
Abhängige Datensätze können erst bei Bedarf geladen werden (on Demand, Lazy Loading Strategy).
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/CompositeEntity.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeEntity.html.
-
DAO, Data Access Object
- Adapter zur Abstrahierung und Entkopplung von Datenzugriffen zum Beispiel auf
relationale und objektorientierte Datenbanken, XML, ERP, Legacy, CORBA, LDAP, B2B, Web Services.
- DAO wird nicht benötigt, wenn
CMP (Container Managed Persistence) verwendet wird.
Nur bei BMP (Bean Managed Persistence) ist der zusätzliche DAO-Layer sinnvoll.
- DAO kann mit O/R-Framework realisiert werden (Object-to-Relational Mapping)
(z.B. Hibernate).
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.
-
Service Activator
- Eine MDB (Message Driven Bean)
als asynchroner JMS-Listener.
- Siehe http://www.corej2eepatterns.com/Patterns2ndEd/ServiceActivator.htm
und http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceActivator.html.
Links auf weiterführende Informationen
- Websites
- Sun J2EE Patterns: http://java.sun.com/developer/technicalArticles/J2EE/patterns
- Sun Java EE BluePrints Architekturreferenz: http://www.oracle.com/technetwork/java/javaee/blueprints
- Design Patterns Java Companion, Cooper: http://www.patterndepot.com/put/8/JavaPatterns.htm
- Design Patterns, Huston: http://home.earthlink.net/~huston2/dp/patterns.html
- The Design Patterns Java Companion, Cooper: http://www.patterndepot.com/put/8/JavaPatterns.htm
- Bücher
- Alur/Crupi/Malks, Core J2EE Patterns, 2003, 0131422464,
Amazon.de
- Broemmer, J2EE Best Practices, 2002, 0471228850,
Amazon.de
- Fowler/Rice/Foemmel, Patterns of Enterprise Application Architecture, 2002, 0321127420,
Amazon.de
- Fowler, Refactoring, 1999, 0201485672,
Amazon.de
- Buschmann/Meunier/Rohnert/Sommerlad/Stal, Pattern-orientierte Software-Architektur, 1998, 3827312825,
Amazon.de
- Gamma/Helm/Johnson/Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software, 1997, 0201633612,
Amazon.de
- Völter/Schmid/Wolff, Server Component Patterns, 2002, 0470843195: Amazon.de
Weitere Themen: andere TechDocs
| UML, MDA
| Softwarearchitekt
| Vorgehensmodelle
© 2002-2007 Torsten Horn, Aachen