Creational Design Patterns Structural Design Patterns Abstract Factory Adapter Client <<interface>> The adapter pattern is used Client ITarget -productA: AbstractProductA to provide a link between -productB: AbstractProductB +MethodA() two otherwise incompatible +Client(factory: AbstractFactory) types by wrapping the Adapter Adaptee "adaptee" with a class that AbstractProductA AbstractFactory AbstractProductB -adaptee: Adaptee +MethodB() supports the interface +CreateProductA(): AbstractProductA +MethodA() +CreateProductB(): AbstractProductB required by the client. ConcreteProductA1 ConcreteProductB1 ConcreteFactoryA Bridge +CreateProductA(): AbstractProductA ConcreteProductA2 +CreateProductB(): AbstractProductB ConcreteProductB2 Abstraction ImplementationBase The bridge pattern is used ConcreteFactoryB +Implementer: ImplementationBase to separate the abstract +CreateProductA(): AbstractProductA +OperationImplementation() +CreateProductB(): AbstractProductB +Operation() elements of a class from the implementation details, RefinedAbstraction ConcreteImplementation providing the means to The abstract factory pattern is used to provide a client with a set +Implementer: ImplementationBase replace the implementation +OperationImplementation() of related or dependant objects. The "family" of objects created +Operation() details without modifying by the factory are determined at run-time. the abstraction. Composite Prototype Component <<interface>> IEnumerable<Component> The composite pattern is Prototype The prototype pattern is used +Operation() used to create hierarchical, to instantiate a new object by recursive tree structures of +Clone(): Prototype children copying all of the properties of related objects where any an existing object, creating an Leaf Composite element of the structure may ConcretePrototypeA ConcretePrototypeB -children: Component[0..*] independent clone. This +Operation() be accessed and utilised in a +Operation() +Clone(): Prototype +Clone(): Prototype practise is particularly useful +AddChild(child: Component): void standard manner. +RemoveChild(child: Component): void when the construction of a new +GetChild(index: int): Component object is inefficient. Decorator Builder ComponentBase The decorator pattern is used +Operation() to extend or alter the Director Builder The builder pattern is functionality of objects at run- +Construct(builder: Builder Classes): void +BuildPart1(): void +BuildPartX(): void used to create ConcreteComponent DecoratorBase time by wrapping them in an +GetProduct(): Product -Component: ComponentBase complex objects with +Operation() object of a decorator class. +DecoratorBase(Component: ComponentBase) constituent parts that +Operation() This provides a flexible Product constructs ConcreteBuilder must be created in alternative to using the same order or inheritance to modify +BuildPart1(): void ConcreteDecorator +BuildPartX(): void using a specific behaviour. +GetProduct(): Product +Operation() algorithm. An +AdditionalOperation() external class controls the Facade Flyweight construction algorithm. FlyweightFactory Package A -Flyweights: FlyweightBase[*] +GetFlyweight(key): FlyweightBase ClassA1 ClassA2 Factory Method Facade FlyweightBase +PerformAction() ProductBase FactoryBase The factory pattern is +StatefulOperation(state) Package B +FactoryMethod(): ProductBase used to replace class constructors, abstracting ClassB1 ClassB2 the process of object ConcreteFlyweight UnsharedFlyweight ConcreteProduct ConcreteFactory generation so that the +FactoryMethod(): ProductBase type of the object The facade pattern is used to The flyweight pattern is used to instantiated can be define a simplified interface to a reduce the memory and resource determined at run-time. more complex subsystem. usage for complex models containing many hundreds, thousands or hundreds of Singleton thousands of similar objects. Singleton The singleton pattern ensures that only one Proxy -instance: Singleton object of a particular class is ever created. -Singleton() +GetSingleton(): Singleton All further references to objects of the singleton class refer to the same underlying SubjectBase The proxy pattern is used to provide a surrogate or placeholder object, which instance. +PerformAction() references an underlying object. The proxy provides the same public Proxy RealSubject interface as the underlying subject -realSubject: RealSubject +PerformAction() class, adding a level of indirection by +PerformAction() accepting requests from a client object and passing these to the real subject object as necessary. http://www.blackwasp.co.uk Behavioural Design Patterns Chain of Responsibility Memento Client HandlerBase The chain of Originator Memento Caretaker +Successor: HandlerBase responsibility pattern is -state -state +Memento: Memento +HandleRequest(request) used to process varied +CreateMemento(): Memento +ctor(state) requests, each of which +SetMemento(memento: Memento) +GetState() may be dealt with by a ConcreteHandlerA ConcreteHandlerB The memento pattern is used to capture the current state of an object different handler. +HandleRequest(request) +HandleRequest(request) and store it in such a manner that it can be restored at a later time without breaking the rules of encapsulation. Command Observer Invoker CommandBase The command pattern SubjectBase ObserverBase +Command: CommandBase #receiver: Receiver is used to express a The observer pattern is -observers: ObserverBase[0..*] +ExecuteCommand() +Execute() request, including the +Update() used to allow an object to +ctor(receiver: Receiver) +Attach(o: Observer) call to be made and all +Detach(o: Observer) publish changes to its +Notify() of its required state. Other objects subscribe to be Client Receiver ConcreteCommand parameters, in a ConcreteSubject ConcreteObserver immediately notified of any +Parameter command object. The +Action() -state -subject: ConcreteSubject changes. +Execute() command may then +GetState() +Update() be executed immediately or held for later use. State Interpreter Context StateBase The state pattern is used to +State: StateBase alter the behaviour of an +Handle(context: Context) +ctor(state: StateBase) object as its internal state Client Context The interpreter pattern +Request() changes. The pattern is used to define the allows the class for an grammar for ConcreteStateA ConcreteStateB object to apparently change instructions that form +Handle(context: Context) +Handle(context: Context) ExpressionBase at run-time. part of a language or +Interpret(context: Context) notation, whilst allowing the grammar to be Strategy TerminalExpression NonterminalExpression easily extended. -expression: ExpressionBase +Interpret(context: Context) +Interpret(context: Context) Client StrategyBase The strategy pattern is used to +Strategy: StrategyBase +Algorithm() create an interchangeable +CallAlgorithm() family of algorithms from which ConcreteStrategyA ConcreteStrategyB the required process is chosen Iterator +Algorithm() +Algorithm() at run-time. Client The iterator pattern is used to provide a Template Method standard interface for AggregateBase IteratorBase traversing a collection AlgorithmBase +CreateIterator(): IteratorBase +First(): object of items in an The template method +Next(): object aggregate object +TemplateMethod() +CurrentItem(): object +Step1() pattern is used to define +IsDone(): bool +Step2() without the need to +Step3() the basic steps of an understand its algorithm and allow the ConcreteAggregate ConcreteIterator underlying structure. ConcreteAlgorithmA ConcreteAlgorithmB implementation of the -aggregate: ConcreteAggregate individual steps to be +CreateIterator(): IteratorBase +Step1() +Step1() +First(): object +Step2() +Step2() changed. +Next(): object +Step3() +Step3() +CurrentItem(): object +IsDone(): bool Visitor Mediator Client MediatorBase ColleagueBase #mediator: MediatorBase +SendMessage(caller: ColleagueBase) +ctor(mediator: MediatorBase) ObjectStructure VisitorBase +Elements: ElementBase[0..*] +Visit(element: ConcreteElementA) +Accept(visitor: VisitorBase) +Visit(element: ConcreteElementB) ConcreteMediator ConcreteColleagueA ConcreteColleagueB +Colleague1: ColleagueA ElementBase ConcreteVisitorA ConcreteVisitorB +Colleague2: ColleagueB +Send() +Send() +Receive() +Receive() +SendMessage(caller: ColleagueBase) +Accept(visitor: VisitorBase) +Visit(element: ConcreteElementA) +Visit(element: ConcreteElementA) +Visit(element: ConcreteElementB) +Visit(element: ConcreteElementB) ConcreteElementA ConcreteElementB +Accept(visitor: VisitorBase) +Accept(visitor: VisitorBase) The mediator pattern is used to reduce coupling between classes that communicate with each other. Instead of classes communicating The visitor pattern is used to separate a relatively complex set of directly, and thus requiring knowledge of their implementation, the structured data classes from the functionality that may be performed classes send messages via a mediator object. upon the data that they hold. http://www.blackwasp.co.uk.