Patterns

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. Im Prototyp-Pattern werden true-copies gemacht, keine shallow-copies.

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.

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. Beispiel in Java: The Iterator pattern allows users to access all the items of the various implementations of the interface java.util.Collection in the same manner.

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.

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

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).

Dependency Inversion Principle

Depend on abstractions. Do not depend upon concretions.

Interface Segregation Principle

Many specific interfaces are better than a single, general interface.

Composite Reuse Principle

Favor polymorphic composition over inheritance. Mann sollte Vererbung nicht als primäre Wiederverwendungsstragegie verwenden.

Principle of Least Knowledge

In einer Methode einer Klasse sollte man nur folgende Objekte verwenden:

• Das Objekt selbst.
• Die Parameterobjekte
• Objekte, die die Klasse selbst erzeugt.
• Die Objekte, die in den Instanzvariablen der Klasse gespeichert sind.

Release Reuse Equivalency Principle

Importiert man ein anderes Package, können alle Klassen dieses Package verwendet werden, auch wenn eigentlich nur eine Klasse benötigt wird.

Common Closure Principle

Klassen, die nur zusammen angepasst werden können, gehören in dasselbe Package.

Common Reuse Principle

Klassen, die nicht zusammen verwendet werden, gehören nicht in dasselbe Package. Folge: Ist eine Klasse abhängig von einer anderen Klasse in einem anderen Package, dass ist diese Klasse von allen Klassen in diesem Package abhängig (indirekt).

Acyclic Dependencies Principle

Keine Zyklen in Package-Dependencies.

Stable Dependencies Principle

Depend in the direction of stability.