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. Anbei ein Beispiel in Java:

public class OracleDAOFactory extends DAOFactory {
   public static CustomerDAO getCustomerDAO(){
      return new OracleCustomerDAO();
   }
   public static EmployeeDAO getEmployeeDAO(){
      return new OracleEmployeeDAO();
   }
}

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.

Participants:

• Target: Das Interface, welches der Client nutzt. Der Adapter implementiert dieses Interface.
• Adaptee: Das Objekt, über welches der Adapter gestülpt wird.
• Adapter: Die Impelmentation des Adapters. Implementiert das Target Interfaces.
• Client: Der Client des Adaptees. Nutzt ausschliesslich das Target Interface.

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.

Bridge decouples an abstraction from its implementation so they can independently vary.

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. Beispiel aus der Java API:

FileInputStream fis = new FileInputStream("t.tmp");
ObjectInputStream ois = new ObjectInputStream(fis); //new functionality is added.

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.

Java Beispiel:

Integer i1 = Integer.valueOf(127);
Integer i2 = Integer.valueOf(128);
System.out.println(i1==Integer.valueOf(127));
System.out.println(i2==Integer.valueOf(128));

Bis 127 muss die JVM die gleiche Instanz für die gleiche Zahl zurückgeben. Über 127 muss nicht gecached werden.

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. Das Pattern ist auch als Action Pattern bekannt.

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.

mediator

Defines an object that encapsulates how a set of objects interact. Promotes loose coupling by keeping objects from referring to each other explicitly. In GUI Programmen kann es vorkommen, dass Objekte mit vielen Objekten verknüpft sind. Jedes UI-Element kennt im Worst-Case alle anderen UI-Elemente. Der Mediator (Director) wirkt dann als Hub zwischen den UI-Elmenten, sie müssen nur noch den Mediator kennen und nicht mehr die anderen UI-Elemente.

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

Beispiel in Java:

public interface Element{
   void accept(Visitor v);
}

public interface Visitor {
   void visitCustomer(Element e);  
   void visitEmployee(Element e);
   void visitEquipment(Element e);
}

public class Equipment implements Element {

   public void accept(Visitor v){
       v.visitEquipment(this);
   }
}

Visitor bietet double dispatch. Für die Wahl des ausführenden Codes sind zwei Sachen massgebend, die Klasse des Visitors und die Klasse des Elements. Will man Element mit Funktionalität erweitern, dann muss nur eine neue Visitor Klasse geschrieben werden, nicht alle Implementationen von Element müssen angepasst werden.

j2ee patterns

presentation tier patterns

intercepting filter

servlet filters. Unterstützt Preprocessing und Postprocessing bei einem Request. Strategies:

• Standard filter strategy: Implementation mit Filter von Servlet 2.3 oder höher.
• base filter strategy: In der Applikation gibt es einen Basisfilter (javax.servlet.Filter), von welchen die anderen Filter erben.
• template filter strategy: Basiert auf der Base Filter Strategy. Impelmentationen sollten einfacher werden, indem sie nur doPreprocessing und do doPostProcessing umsettzen.

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:

• Servlet Front Strategy
• Jsp Front Strategy
• Physical Resource Mapping Strategy: JSP URLs sind nicht logisch sondern hardcoded im Dispatcher-Logik. Es gibt keine Konfigurationsdatei in XML wie bei Struts. Nicht so flexibel.
• Logical Resource Mapping Strategy:
• Multiplexed Resource Mapping Strategy: Subform von Local Resource Mapping Strategy. z.B. Struts.
• Dispatcher in Controller Strategy: Wenn das Dispatching einfach ist, braucht es nicht eine extra Klasse für das Dispatching.
• Base Front Strategy
• Filter Controller Strategy: Aspekte vom Controller werden in einem Filtr implementiert.

Context Object

Protokollspezifisches mit Context Objekten verstecken und abstrahieren. Contexte werden vielfach mit einer RequestContextFactory erstellt.

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
• 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. Participants:

• Mapper: Der Mapper benutzt die Map, um für den Request die entsprechende View und Action ausfinding zu machen.
• Map: Container für Resource-Handles.(indirekte oder direkte Handles).
• Target:
• ApplicationController: Schaltzentrale. Bekommt Requests vom Client und benutzt Mapper und Map und weiteres.
• Client: Der Client ist ein FrontController oder ein Intercepting Filter.

Command Handler: Sucht mit Mapper das Command (oder Action) und ruft dort die execute Methode auf.

View Handler: Sucht die nächste View mit dem Mapper und macht z.B. ein request.getRequestDispatcher(pathtojsp). forward(request, response)

View Helper

Ein View Helper ist ein POJO, welchers zwischen View und Model sitzt. Es ist also ein Adapter zwischen View und Modell. Ein Helper kann HTML erzeugen, z.B. Table-Tags. View Helper könnte sein: JavaBean, CustomTag, TagFile, BusinessDelegate. Der Unterschied zwischen BusinessDelegte und ViewHelper: BusienssDelegate wird von einem Business Component Developer geschrieben, View Helper von einem Web Component Developer. 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. Service to Worker ist das gesamte Zusammenspiel zwischen Front-Controller, ApplicationController, View, BusinessHelper, ViewHelper, BusinessService, PresentationModel.

Dispatcher View

Businesslogik wird direkt in der View aufgerufen. Für Applikationen mit wenig Geschäftslogik.

business tier patterns

Business Delegate

Clients (Webapplikationen oder B2B Clients) gehen über das BusinessDelegate, um mit einem BusinessService zu kommunizieren. Benutzt vielfach ServiceLocator Pattern.

Konsequenzen:

• Reduziert Coupling
• Verbessert Maintainablility
• Entpackt Exceptions (remote Exceptions)
• Verbessert Availability (recovery attempt)
• Einfacheres interface zum Business Tier
• Verbesserte Performance (cache)
• Zusätzlicher Layer
• Versteckt Remoteness

Service Locator

Kann Einträge im JND cachen. Kann auch mit EJB Handles arbeiten. Kann auch Funktionen für Webservice UDDI enthalten.

Session Facade

Sun empfielt, nicht pro Use Case eine Facade zu erstellen. Die einzelnen Facaden wären dann nicht mehr coarse-grained sein, sondern fine-grained. Es gibt stateless Session Facades und Stateful Session Facades. Pro Session Facade wird in der Regel ein BusinessDelegate erstellt.

Konsequenzen:

• Neuer Layer. Könnte Overhead generieren.
• Uniformelles coarse-grained interface.
• Reduziert Coupling zwischen den Tiers.
• Erhöht Flexibility und Maintainablility
• Reduziert Komplexität
• Verbessert Performance, indem die Anzahl von remote Method Invocations reduziert wird. Also weniger fine-grained remote methods.
• Zentralisiert Security-Management.
• Zentralisiert transactional Control
• Weniger remote Interfaces

Application Service

ApplicationServices sind zwischen Session-Facades und Business-Objects (in EJB Applikationen).

• ApplicatonServices sind finer-grained als Session-Facades.
• ApplicationServices sind coarser-grained als Business-Objects.

Regel: Logik, die für alle Requests von allen Clients gleich ist, wird am besten in die BusienssObjekte integriert. Logik, die Request-Type spezifisch ist, wird in den ApplicationServices integriert.

Konsequenzen:

• Zentralisiert busienss und workflow Logik.
• Verbessert Reusablility von Business Logik. Ein AppService kann in mehreren UseCases verwendet werden.
• Weniger Copy Paste
• FacadeImplementationen werden einfacher.
• Neuer Layer im Business Tier.

Business Object

Business Objekte trennen Geschäftsdaten und Geschäftslogik. Sun emphielt, dass Business Objekte nicht Transferobjekte wrappen sollen.

Composite Entity

Strategies:

• Lazy Loading Strategy: DependentEntities werden nur bei Bedarf geladen.
• Store Optimization (Dirty Marker) Strategy: Nur veränderte Dependent-Entities werden gespeichert.

Konsequenzen:

• Verbessert Maintainablility: Weniger Entity Beans.
• Verbessert Netzwerk-Performance
• Reduziert Abhängikeit zum Datenbankschema: Das Schema wird vor den Clients versteckt.

Transfer Object

Transferieren Daten zwischen den Tiers und Layers.

Konsequenzen:

• Reduziert Network-Traffic
• Vereinfacht remote Objects und remote Interfaces
• Transferiert mehr Daten in weniger remote Calls.
• Reduziet Copy-Paste
• Stale Transfer-Objekte sind leider möglich.
• Erhöht Komplexität, weil Version Control (Optimistic Locking) und Datenbanksynchronization gemacht werden muss.

Transfer Object Assembler

Der Transfer-Objket Assembler aggregiert verschiedene Transferobjekte von verschiedenen Busienss-Components und Services und gibt dem Client ein Composite-Transfer-Objekt zurück.

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.

Um die DAOs zu erzeugen, wird oft das Factory Method und Abstract Factory Pattern verwendet.

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.

Ist also bekannt unter Law of Demeter.

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.