[.] DejaVU Online: -- The OO Lectures
[.] - [up] [top] - [I] [II] [III] [IV] - [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] - [A] [R]

Introduction

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

slide: Phrases ..

Motivation

Take for example a document processing system ...

  • material - words, images, tables
  • formatting, layout
  • online presentation and editing tool
slide: Document processing

Managing composites

Problem: very many items

Solution: flyweight class

slide: Composite ...
slide: Composite

Managing layout and formatting

Problem: many algorithms

Solution: composer (strategy) class
slide: Strategy ...
slide: Strategy

Display item with attributes

Problem: non-uniform attributes

Solution: embed and hide attributes
slide: Decorate ...
slide: Decorator

Develop multi-platform tools (1)

Problem: different window toolkits

Solution: employ platform-specific factories
slide: Factory ...
slide: Factory

Develop multi-platform tools (2)

Problem: offer uniform widget hierarchy

Solution: separate interface from implementation
slide: Bridge ...
slide: Bridge

Provide rich functionality

Problem: support commands with undo

Solution: abstract from specific commands

slide: Command ...
slide: Command

A Catalogue of Patterns

A Catalogue of Design patterns

  • 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

slide: A Catalogue of Design patterns

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
slide: The Pattern Schema

Causes for Redesign

design for change

  • creating an object by specifying a class explicitly -- Abstract Factory, Factory Method, Prototype
  • dependence on specific operations -- Chain of Responsibilty, Command
  • dependence on hardware & software platforms -- Abstract Factory, Bridge
  • dependence on object implementation or representation --Abstract Factory, Bridge, Memento, Proxy
  • algorithm dependence -- Builder, Iterator, Strategy, Template Method, Visitor
  • extending functionality by subclassing -- Bridge, Chain, Composite, Decorator, Observer
  • tight coupling -- Abstract Factpry, Bridge, Chain of Responsibilities, Command, Facade, Mediator, Observer
  • inability to alter classes conveniently -- Adaptor, Decorator, Visitor
slide: Causes for Redesign

Kinds of Patterns

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

see UML

slide: Kinds of Patterns

Design Patterns

Design Patterns
slide: Design Patterns

Creational Patterns

Factory

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

Example

Also known as kit

Paricipants

  • 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
slide: Factory

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
slide: Factory Method

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
slide: Singleton

Prototype

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

Motivation

  • flexibility, reduce number of classes

Applicability

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
slide: Prototype

Structural Patterns

Structural Patterns

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

slide: Structural Patterns

Language mechanisms

  • inheritance -- class
  • delegation -- object

Adaptor versus 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
slide: Idioms or Language mechanisms

Behavioral Patterns

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
slide: Behavioral Patterns

Encapsulating behavior

objectify!
  • Strategy -- algorithm
  • Command -- request
  • State -- object state -> behavioral change
  • Visitor -- to extract behavior from class
  • Iterator -- access and traversal
slide: Encapsulating behavior

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
slide: Observer Pattern
[.] - [up] [top] - [I] [II] [III] [IV] - [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] - [A] [R]
Hush Online Technology
hush@cs.vu.nl
02/15/00