methods do not provide the intuiton and the direct access to solutions that work in real life. design patterns are the jewels, the cristals of object oriented design ...

take for example a document processing system ...

• material - words, images, tables
• formatting, layout
• online presentation and editing tool

managing composites

problem -- very many items

solution -- flyweight class

managing layout and formatting

problem -- many algorithms

solution -- composer (strategy) class

display item with attributes

problem -- non-uniform attributes

solution -- embed and hide attributes

develop multi-platform tools (1)

problem -- different window toolkits

solution -- employ platform-specific factories

develop multi-platform tools (2)

problem -- offer uniform widget hierarchy

solution -- separate interface from implementation

provide rich functionality

problem -- support commands with undo

solution -- abstract from specific commands

design pattern(s) -- catalogue

• a common design vocabulary
• documentation and learning aid
• an adjunct to existing methods
• a target for redesign

see the GOF Design Patterns and the Patterns Homepage

the pattern schema

structure

name - handle

• increases design vocabulary

problem - when to apply

• explains the problem and the conflict

solution - general arrangement

• design, responsibilities, collaborations

consequences - tradeoffs

• to understand the costs and benefits

causes for redesign

design for change

1. creating an object by specifying a class explicitly -- Abstract Factory, Factory Method, Prototype
2. dependence on specific operations Chain of Responsibilty, Command
3. dependence on hardware & software platforms -- Abstract Factory, bridge
4. dependence on object implementation or representation Abstract Factory, Bridge, Memento, Proxy
5. algorithm dependence -- Builder, Iterator, Strategy, Template Method, Visitor
6. extending functionality by subclassing -- Bridge, Chain, Composite, Decorator, Observer
7. tight coupling -- Abstract Factpry, Bridge, Chain of Responsibilities, Command, Facade, Mediator, Observer
8. inability to alter classes conveniently -- Adaptor, Decorator, Visitor

kinds of patterns

• creational patterns -- factory, singleton, ...
• structural patterns -- adaptor, composite, bridge, ...
• behavioral patterns -- mediator, observer, command, ...

see also

see UML

design patterns

creational

• factory
• singleton

  structural

• adaptor
• bridge

  behavioral

• strategy
• observer

factory

provide interface for creating family of related or dependent objects without specifying their concrete classes

Example

also known as kit

participants

• AbstractFactory, Concrete Factory, Abstract Product, Concrete Product

consequences

• isolate concrete classes
• makes exchanging product families easy
• promotes consistency among products
• supporting new kinds of products is difficult

implementation

See GOF

factory method

define interface for creating an object, but let subclass decide which class to instantiate

also know as

virtual constructor

motivation

• encapsulates knowledge of which subclass to instantiate

applicability

• when a class can not anticpate the class of the objects it creates
• to delegate responsibility of object creation

structure

participants

• Product, ConcreteProduct, Creator, ConcreteCreator

consequences

• provide hooks for subclasses
• connects parallel class hierarchies

related

• Factory, Prototype

singleton

ensure a class has only one instance and provide a global point of access

applicability

• only one instance of a class
• instance must be extendable by subclassing

implementation

     // .h file 
  
     class Singleton {
     public:
  	static Singleton instance();
     protected: 
 limit access
  	Singleton();
     private:
  	static Singleton* _instance;
     };
  
  
     // .c file
  
     Singleton* Singleton::_instance = 0;
  
     Singleton* Singleton::instance() {
  	if (_instance == 0)
  		_instance = new Singleton();
  	return _instance;
  	}
  

consequences

• coordinate access to a single instance
• reduced namespace
• permit refinement
• permit variable number of instances

etcetera

see GOF

prototype

specify kinds of objects to create using a prototypical instance and create by copying this prototype

motivation

• flexibility, reduce number of classes

applicability

• when classes to instantiate are specified at runtime
• to avoid building a class hierarchy of factories
• to reduce static dependencies

participants

• Prototype, ConcretePrototype, Client

consequences

• adding and removing product types at runtime
• specifying new objects by varying value/structure
• reduced subclassing
• configure an application with classes dynamically see kit.h and dv/tk/kit.c

related

• AbstractFactory versus Prototype

structural patterns

are concerned with how classes and objects are composed to form larger structures

Pattern	Alias	Remarks

language mechanisms

• inheritance -- class
• delegation -- object

adaptor vs bridge

wrapper

• adaptor -- resolves inconsistencies between interfaces
• bridge -- relates abstraction to ... implementation

Composite vs Decorator vs Proxy

recursive composition

• Composite represents structure
• Decorator adds responsibilities
• Proxy regulates access

behavioral patterns

communication

deal with algorithms and the assignment of responsibilities between objects

class

• template method -- the skeleton of an algorithm
• interpreter -- to evaluate expressions

object

composition

• mediator -- provides indirection for loose coupling
• chain of responsibility -- connect objects to interact
• observer -- to handle dependencies

encapsulating behavior

objectify!

• strategy -- algorithm
• command -- request
• state -- object state -> behavioral change
• visitor -- to extract behavior from class
• iterator -- access and traversal

observer

one-to-many dependencies and notification

structure

consequences

• abstract coupling between subject and observer
• support for broadcast
• deals with unexpected updates

implementation

• mapping subjects to observers
• observing more than one subject?
• who triggers the update - subject or client of subject
• dangling references to subject
• consistency of subject (before notification)
• adding observer-specific update protocols (push / pull)
• specifying modifications of interest (aspects)
• how to encapsulate update semantics