Knowledge of design patterns
is crucial for any kind of serious software development.
Let's learn what they are, what they are good for, and
the names of, and basic ideas behind, a few of the more
"Each pattern describes a problem which occurs over and over
again ... 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 doing it the same way twice." -- Christopher Alexander
Design Patterns for Object-Oriented Software
Design Patterns are not analysis patterns, are not descriptions
of common structures like linked lists, nore are they detailed application
or framework designs. Design Patterns are "descriptions of communicating
objects and classes that are customized to solve a general design problem
in a particular context." -- Gamma et al.
Good design patterns help make your software more flexible
Why study design patterns
- Experts in software architecture and design are highly paid, because
they know how to create designs that are flexible, elegant, and
- You become an expert through experience, reusing solutions that worked
for you before.
- Patterns describe solutions to design problems that occur over
and over again.
- Patterns also record design decisions, alternatives, and trade-offs
gained from experience.
- Once you know the pattern, many design decisions follow.
- Knowing patterns helps you get designs right faster.
- Knowing the vocabulary surrounding patterns helps communication
between designers, and can ease the documentation effort.
Common themes in design patterns
Design patterns are used by experts to make their designs more
flexible and reusable, so in studying them you tend to see:
- decoupling of classes or objects, so something can be
changed without changing something else. "Each design pattern lets
some aspect of the system vary independently of other aspects,
thereby making a system more robust to a particular kind of
- elements in a pattern which know how to do one general thing
very well and don't know much about anything else.
- efforts to simplify code, to make it more readable, more
- a major emphasis on interfaces ("program to an interface,
not to an implementation"), and on the distinction between
types and classes.
- a favoring of object composition over class inheritance:
too much inheritance leads to an explosion of the number of
classes in a system.
Some real-world examples
- Smalltalk's MVC uses Observer to describe the relationship
between views and a model, Composite to describe nested
views, and Strategy for the relationship between controllers
- In the Java AWT, components are composites, layout managers are
strategies, and observers are used to monitor image loading.
- Most application frameworks use factory methods to create
the right kind of document.
The 23 patterns from the book
|Chain of Responsibility|
Patterns are for Reuse
Each pattern lets you vary some aspect of the system.
Causes of redesign and patterns that address them:
- Specifying the class of an object explicitly (Abstract Factory, Factory
- Hard coding requests (Command, Chain of Responsibility)
- Hardware and software platform dependencies (Abstract Factory, Bridge)
- Dependence on object representations and implementations (Abstract Factory, Memento, Bridge, Proxy)
- Algorithmic dependencies (Strategy, Builder, Iterator, Template Method, Visitor)
- Tight coupling (Facade, Mediator, Observer, Command, Abstract Factory, Bridge)
- Subclassing to extend functionality (Bridge, Composite, Decorator, Chain of Responsibility, Composite, Strategy)
- Inability to alter classes conveniently (Visitor, Decorator, Adapter)
Patterns in the Document Editor Case Study
- Composite to represent the structure of the document. Glyphs can be nested
- Strategy to allow different formatting algorithms
- Decorator to add borders, etc. to the user interface
- Abstract Factory to support multiple look-and-feel standards
- Bridge to allow it to run on multiple windowing platforms
- Command to support undo
- Iterator to traverse object structures
- Visitor to allow for adding new analytical capabilities
Start by studying the easiest patterns first
Adapter, Decorator, Composite, Observer, Template Method,
Factory Method, Abstract Factory, Strategy.
List of the Original 23 Patterns
||Aspect(s) that can vary
||families of product objects
how a composite object gets created
subclass of object that is instantiated
class of object that is instantiated
the sole instance of a class
||interface to an object
|Bridge||implementation of an object|
|Composite||structure and composition of an object|
|Decorator||responsibilities of an object without subclassing|
|Facade||interface to a subsystem|
|Flyweight||storage costs of objects|
|Proxy||how an object is accessed; its location|
||Chain of Responsibility||object that can fulfill a request|
|Command||when and how a request is fulfilled|
|Interpreter||grammar and interpretation of a language|
|Iterator||how an aggregate's elements are accessed, traversed|
|Mediator||how and which objects interact with each other|
|Memento||what private information is stored outside an object, and when|
|Observer||number of objects that depend on another object; how the dependent objects stay up to date|
|State||states of an object|
|Template Method||steps of an algorithm|
|Visitor||operations that can be applied to object(s) without changing their class(es)