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.

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.

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:

• Servelt 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.

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.

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.