A Few More Patterns



  • Christopher Alexander - Architect (Father of Pattern Movement)
  • Christopher Alexander says:

    "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"

  • Alexander’s books (late 1970’s)
  • OOPSLA 1987
  • Gang of Four (GOF) book 1995
  • The Quality Without A Name

    … the feeling you get when you know that a design is good and right and elegant. It is a feeling that transcends description …

Types of Patterns

    • Design (You Are Here)
    • Analysis
    • Organizational

Granularity of Patterns

Idioms (low level)

      • for(;;)
      • Linked list, tree
      • Composition, delegation (maybe)
      • Polymorphism, inheritance (maybe)
      • Coplein’s Handle/Body Idiom (precursor)

Design Patterns (medium level)

      • Here Be Patterns (In the middle)

Framework (high level)

      • Model View Controller (MVC)(big pattern)(cannonical "Input/Process/Output" trichotomy?)
      • OWL
      • MFC

Types of Design Patterns


  • Bridge
  • Composite


  • Singleton
  • Builder
  • Factory
  • Abstract Factory
  • Prototype


  • Visitor

Pattern Map

23 patterns (GOF)

(Most diagrams are from the GOF CD)

LSP - Liskov Substitution Principle (Barbara Liskov)

  • IS-A relationaship
  • proper inheritance (require no more, promise no less; keep the contract)
  • AKA total polymorphsm
  • in c++, use public inheritance
  • any subclass (derived) class may be used in any correct program.
  • you can always pass a reference to a derived object to a function that expects a reference to a base (or super) class.

DIP - Dependency Inversion Principle (Robert Martin)

  • Adds a level of indirection
  • Reverses dependencies
  • Almost all patterns add one or more levels of indirection
  • DIP diagram (before)
    • Client---->Server
    • Client depends on Server
  • DIP diagram (after)
    • Client----->SeverInterface<------ServerImplementation
    • Client depends on ServerInterface
    • ServerImplementation depends on ServerInterface
    • Changes in the ServerImplementation do not affect the Client

Structural Patterns

Bridge (AKA Handle/Body - Coplien)


  • Intent
    • Decouple an abstraction from its implementation so that the two can vary independently.
  • Motivation
    • If an astraction can have one of several possible implementations then usually we use inheritance.
    • An abstract class defines the interface to the abstraction and concrete subclasses implement it in different ways.
    • Inflexible - inheritance binds an implementation to the abstraction permanently, which makes it difficult to modify, extend, and reuse abstractions and implementations independently.
  • Consequences
    • Vary implementation at run-time (Plug and Pray)
    • Hides implementation
  • Relation to Adapter
    • The Adapter pattern makes things work after they're designed;
    • Bridge makes them work before they are designed.

Bridge Class Diagram

Open/Closed Principle (Bertrand Meyer)

  • open for extension
  • closed for modification


Compose objects into recursive tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.


  • you want to represent part-whole hierarchies of objects.
  • you want clients to be able to ignore the difference between compositions of objects and individual objects.


  • The key to the Composite pattern is an abstract class that represents both primitives and their containers.


  • Makes the client simple. Clients can treat composite structures and individual objects uniformly.
  • Makes it easier to add new kinds of components.
  • May make your design overly general (harder to restrict the components) .
  • Keeps type information at the expense of safety.

Composite Class Diagram

Equipment Diagram

Creational Patterns

Creational Patterns

  • Abstract the instantiation process.
    • A class creational pattern uses inheritance to vary the class that's instantiated
    • An object creational pattern will delegate instantiation to another object.
  • Recurring Themes
    • Encapsulate knowledge about which concrete classes the system uses.
    • Hide how instances of these classes are created and put together.
  • Consequences
    • Flexibility in
      • who creates it
      • what gets created
      • how it gets created
      • when it gets created.


  • Simplest
  • Restrict the number of instances.

Singleton Class Diagram

Enumerated Types in Java

Good News: You can do anything you want
Bad News: You have to do everything you want

Enumerated Types -

Meanwhile back in the Dungeon

Maze Diagram (without patterns)

Maze Diagram


The create() function is pretty complicated, considering that all it does is create a maze with two rooms.
Inflexibility. It hard-codes the maze layout.

The creational patterns show how to make this design more flexible, not necessarily smaller.
Suppose you wanted to reuse an existing maze layout for a new game containing enchanted mazes.
How can you change CreateMaze easily so that it creates mazes with these new classes of objects?

Use Creational Patterns

Creational patterns provide different ways to remove explicit references to concrete classes from code that needs to instantiate them:

If CreateMaze calls virtual functions instead of constructor calls to create the rooms, walls, and doors it requires, then you can change the classes that get instantiated by making a subclass of MazeGame and redefining those virtual functions. This approach is an example of the Factory Method pattern.

If CreateMaze is passed an object as a parameter to use to create rooms, walls, and doors, then you can change the classes of rooms, walls, and doors by passing a different parameter. This is an example of the Abstract Factory pattern.

If CreateMaze is passed an object that can create a new maze in its entirety using operations for adding rooms, doors, and walls to the maze it builds, then you can use inheritance to change parts of the maze or the way the maze is built. This is an example of the Builder pattern.

If CreateMaze is parameterized by various prototypical room, door, and wall objects, which it then copies and adds to the maze, then you can change the maze's composition by replacing these prototypical objects with different ones. This is an example of the Prototype pattern.

Abstract Factory

Abstract Factory Class Diagram



Builder Class Diagram


Factory Diagram

Behavioral Patterns



  • Represent an operation to be performed on the elements of an object structure.
  • Visitor lets you define a new operation without changing the classes of the elements on which it operates.


  • Most Complex
  • Resolves lost type information
  • Avoids downcast

Double Dispatch

  • Some languages do this
  • Java does not
  • Java has single dispatch
  • Virtual function dispatches on actual run-time type of the object
  • No dispatching on arguments

You call me, I’ll call you back

Vistor Class Diagram

Two class hierarchies:

  • one for the elements being operated on (the Element hierarchy)
  • one for the visitors that define operations on the elements (the Visitor hierarchy).

Create a new operation by adding a new subclass to the visitor class hierarchy.
If Node hierarchy does not change, we can add new functionality simply by defining new NodeVisitor subclasses.

Visitor Timing Diagram


Visitor visitor=new ConcreteVisitor1(); // roll up a new Visitor that is-a ConcreteVisitor1

Element element=new ConcreteElementA(); // roll up a new Element that is-a ConcreteElementA

element.accept(visitor); // first dispatch, polymorph on type of element (i.e. ConcreteElementA)

visitor.visitConcreteElementA(this); // second dispatch, polymorph on type of visitor

// (i.e. ConcreteVisitor1) - come visit me, here i am

Pizza (A Little Java, A Few Patterns)

Martin's Visitor (triple dispatch)



  • Fundamental Software Building Blocks
  • No Silver Bullet
  • Design at a Higher Level of Abstraction
  • Increased Communication (Pattern Language)
  • Programmers Handbook
  • Patterns appear at many levels (fractal design methodology?)
  • Just Another Way of Being Inefficient


  • "Design Patterns : Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, (Gang of Four)
  • "Design Patterns CD : Elements of Reusable Object-Oriented Software" by Gamma et. al. (Most of the diagrams in this document were taken from this source)
  • "Pattern Hatching" by John Vlissides
  • "Pattern Languages of Program Design" I ,II, III
  • "A System of Patterns" by Buschmann et. al. (Siemens, Gang of Five)
  • "The Patterns Handbook: Techniques, Strategies, and Applications" by Linda Rising
  • "A Little Java, A Few Patterns" by Matthias Felleisen and Daniel P. Friedman.
  • "Patterns in Java Volime I" by Mark Grand
  • "Advanced C++ Programming Styles and Idioms" by James O. Coplien
  • "Designing Object-Oriented C++ Applications Using The Booch Method" by Robert C. Martin
  • "C++ FAQS" by Marshall P. Cline and Greg A. Lomow