Patterns
Contents
gang of four
creational patterns
abstract factory
Participants sind abstract factory, concrete factory, abstract product, concrete product und der client. In einer konkreten Factory können verschiedene Objekte erstellt werden.
Pro Implementation eines Interfaces gibt es eine andere FactoryImplementation. Das ist der wesentliche Unterschied zu FactoryMethod.
Beispiel:
Je nach Konfiguration im persistence.xml wird eine andere Implementation von JPA zurückgegeben.
EntityManagerFactory emf = Persistence.createEntityManagerFactory("HibernateSamplePU");
EntityManager em = emf.createEntityManager();
builder
Participants sind Builder, Concrete Builder, Director und Product. Im Unterschied zu abstract factory wird das Produkt in mehreren Schritten durch den Director erstellt.
factory method
Participants sind product, concrete product, creator und concrete creator.
prototype
Um eine neue Instanz zu kreieren, wird eine bestehende gecloned. Participants sind prototype, concrete prototype und client. Es gibt vielfach eine prototype registry. Neue prototypen könnten zur Laufzeit hinzugefügt werden.
singleton
Nur eine Instanz einer Klasse existiert. Globaler Accesspoint wird definiert.
structural patterns
adapter
Adapter ermöglicht das Zusammenarbeiten von inkompatiblen Interfaces. Participants: Target, Client, Adaptee, Adapter. Der Adapter bietet den client das Interface des Targes an, welches also anders ist als das des Adaptees. Das Adapterpattern wird eher bei Redesign eingesetzt.
bridge
Dieses Pattern ist eher für C++ wichtig, da es dort keine Interfaces gibt. Das Bridge Pattern bietet zwei parallele Klassenhierarchien. Eine Klassenhierarchie bietet quasi nur die Interfaces an, die andere Klassenhierarchie die Implementation. Der Client arbeitet nur mit der abstrakten Hierarchie.
In der Regel verwendet man bei dem Bridge Pattern auch Abstract Factory.
composite
Knoten einer Baumstruktur sind gleichzeitig Container aber auch Primitive. In einer abstrakten Klasse werden sowol Containerfunktionen (z.B. AddComponent) aber auch Primitivfunktionen (z.B. Draw) definiert.
decorator
Manchmal soll weitere Funktionalität nur bestimmten Objektinstanzen hinzugefügt werden, nicht der ganzen Klasse. Dazu werden die Objektinstanzen in Decorators gepackt (wrapped). Der Dekorator stellt das gleiche Interface wie die gewrappte Klasse zur Verfügung, so merkt der Clients nichts von der Dekoration.
facade
Ein Subsystem bietet ein Interface an, welches von Clients verwendet wird. Die Clients brauchen keine Kenntniss über die Innereien eines Subsystems.
flyweight
Ein flyweight ist ein shared object das in mehreren Contexten gleichzeitig gebraucht werden kann. Bitmaps vom Alphabet ist ein Beispiel.
proxy
Beispiele:
- remote proxy
- virtual proxy für lazy loading
- protection proxy
- smart pointers
behavioral patterns
chain of responsibility
Dieses Pattern ist analog zu ServletFiltern oder EJB3 Interceptors.
command
Ein Request, z.B. Dokument Öffnen, wird in ein Objekt verpackt. Undo Fuktion kann man eventuell auch implementieren, in dem man die Request in eine Queue abspeichert.
interpreter
iterator
Das Iterieren über die Elemente einer Liste wird in eine Iterator-Klasse ausgelagert. Mit dem Pattern ist es möglich, z.B. einen Iterator zu impelmentieren, der Elemente herausfiltert.
memento
Memento ist ein Objekt, das den internen Zustand eines anderen Objektes (Originator) speichert (snapshot). Dieses Pattern ist hilfreich bei undo Operationen.
observer
Auch bekannt als publish/subscribe.
state
Objekte zeigen verschiedenes Verhalten, je nach Status in dem sie sich befinden. Als ob es eine andere Klasse wäre (pro Status). Dazu zeigt der Context das Inteface zum Client. Es gibt ein State Basisklasse (oder Interface), welche dann von den Stati-Implementationen erweitert wird.
strategy
Für eine Aufgabenstellung gibt es verschiedene Algorithmen, welche die Aufgabe lösen. Mit dem Strategy Pattern wird dem Client mit dem Context ein Interface zur Verfügung gestellt, welches für alle diese Algorithmen geeignet ist. Jeder Algorithmus erbt dann von Strategy. Mit dem Pattern kann der Algorithmus einfach ausgetauscht werden, ohne dass der Client geändert werden muss.
template method
Mit dem template method pattern wird in einer abstrakten Klasse das Skelett eines Algorithmus definiert. Konkrete Klassen implementieren die abstrakten Schritte des Skeletts. So etwas wie Inversion of Control.
visitor
j2ee patterns
presentation tier patterns
intercepting filter
servlet filters. Strategies:
- base filter strategy
- template filter strategy
front controller
Zentraler Zugang zu einer Webapplikation immer über das gleiche Servlet oder die gleichen Servlets. Front Controller delegiert calls zu ApplicationController. Der ApplicationController ist aber kein Servlet.
Strategies:
- Servelt Front Strategy
- Jsp Front Strategy
- Physical Resource Mapping Strategy: JSP URL sind nicht logisch sondern hardcoded. Nicht so gut.
- Logical Resource Mapping Strategy:
- Multiplexed Resource Mapping Strategy: Subform von Local Resource Mapping Strategy. z.B. Struts.
- Dispatcher in Controller Strategy
- Base Front Strategy
- Filter Controller Strategy
Context Object
Protokollspezifisches mit Context Objekten verstecken und abstrahieren.
Strategies:
- Request Context Strategies
- Request Context Map Strategy
- Request Context POJO Stategy
- Request Context Validation Strategy
- Configuration Context Strategies
- Security Context Strategy
- General Context Object Strategies
- RequestContextFactory
- Context Object Auto-Population Strategy
Application Controller
Der Applicationcontroller nimmt folgende Aufgaben wahr:
- action management
- view management
Der Frontcontroller übergibt dem Application Controller kein HttpServletRequest, sondern ein Context Objekt.
View Helper
Ein View Helper ist ein POJO Adapter, welcher zwischen View und Model sitzt. Strategies:
- Template-Based View Strategy: Views mit JSPs
- Controller-Based View Stategy: Views mit Servlets.
Composite View
Prefered way: custam tag view management strategy. Ist in etwa Tiles oder Facelets.
Service To Worker
Business Methoden werden ausgeführt bevor die View gerendert wird.
Dispatcher View
Businesslogik wird direkt in der View aufgerufen. Für Applikationen mit wenig Geschäftslogik.
business tier patterns
Business Delegate
Service Locator
Session Facade
Application Service
Business Object
Composite Entity
Transfer Object
Transfer Object Assembler
Value List Handler
Man hat eine Suche ohne updates und ohne Transaktion. Man umgeht die ejbFinder Methoden von Entity Beans 2.X, weil diese grossen Overhead mit sich bringen. In diesem Pattern wird die ReadOnly Suche über ein DataAccessObject durchgeführt. Dem Client wird nur eine Page übermittelt. Das ganze Resultat wird in einer ValueList gespeichert. Am besten eine seperates stateful Session Bean für die Implementation verwenden.
integration tier patterns
Data Access Object
Das DAO ist stateletss, kein Cache wegen Threading Issues. Pro DomainObject gibt es in der Regel ein DAO: CustomerDAO, EmployeeDAO.
Strategies:
- Transfer object collection strategy: Zusätzlich finders zu create, update, insert und delete.
- Cached row set stratety: Zusätzlich noch ein Cache einbauen, z.B. mit RowSet.
- Read Only Row Set Strategy: Einige RowSet Implementationen erlauben updates. Mit dieser Strategy wird dies verhindert.
- RowSet Wrapper List Strategy: Dem Client wird nicht ein RowSet zurückegeben, sondern eine java.util.List.
Service Activator
Der Service Activator ist ein JMS Listener. Der Service Activator macht dann Calls zu Business Services.
Domain Store
Wenn man JPA, JDO, Hibernate, OJB braucht oder selber etwas bastelt.
Web Service Broker
Strategies:
- POJOBroker
- SessionBeanJAXBroker
- POJOJAXBroker
Diverses
Tiers
j2ee tiers
In j2ee gibt es presentation tier, business tier, integration tier und resource tier.
- persentation tier: servlets, controllers, jsps
- business tier: entity beans, session beans
- integration tier: data access objects
- resource tier: Resource, data and extrnal services.
Principles
Open Closed Principle
Classes shoud be open for extension but closed for modification.
Liskov Substitution Principle
Subclasses should be substituble for their base classes. Ist eine Erweiterung zum Open Closed Principle. Klassen, welche das Liskov Substitution Principle verletzten, verletzen auch das OCP, aber nicht umgekehrt. Der Unterschied zum OPC ist, dass LSP auf Preconditions und Postconditions beruht. Liskov's notion of a behavioral subtype defines a notion of substitutability for mutable objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness).