Praise for Design Patterns
This book isn't an introduction to object-oriented technology or
design. Many books already do a good job of that. This isn't an
advanced treatise either. It's a book of design patterns that describe
simple and elegant solutions to specific problems in object-oriented
software design.
Once you understand the design patterns and have had an "Aha!"
(and not just a "Huh?" experience with them, you won't ever think
about object-oriented design in the same way. You'll have insights that
can make your own designs more flexible, modular, reusable, and
understandable - which is why you're interested in object-oriented
technology in the first place, right?
Index
INDEX ........................................................................................................ 5
OVERVIEW ................................................................................................. 6
ABSTRACT FACTORY ................................................................................ 10
ADAPTER ................................................................................................. 14
BRIDGE .................................................................................................... 18
BUILDER .................................................................................................. 24
CHAIN OF RESPONSIBILITY ....................................................................... 28
COMMAND .............................................................................................. 32
COMPOSITE ............................................................................................. 36
DECORATOR ............................................................................................ 41
FACADE ................................................................................................... 47
FACTORY METHOD .................................................................................. 51
FLYWEIGHT .............................................................................................. 56
INTERPRETER ........................................................................................... 60
ITERATOR ................................................................................................ 63
MEDIATOR .............................................................................................. 67
MEMENTO ............................................................................................... 72
NULL OBJECT ........................................................................................... 75
OBJECT POOL ........................................................................................... 80
OBSERVER ............................................................................................... 84
PRIVATE CLASS DATA ............................................................................... 88
PROTOTYPE ............................................................................................. 90
PROXY ..................................................................................................... 94
SINGLETON .............................................................................................. 97
STATE .................................................................................................... 101
STRATEGY .............................................................................................. 105
TEMPLATE METHOD .............................................................................. 109
VISITOR ................................................................................................. 113
ABOUT THE AUTHOR ............................................................................. 119
Index | 5
Overview
In software engineering, a design pattern is a general repeatable
solution to a commonly occurring problem in software design. A design
pattern isn't a finished design that can be transformed directly into code.
It is a description or template for how to solve a problem that can be used
in many different situations.
Design patterns can speed up the development process by providing
tested, proven development paradigms. Effective software design requires
considering issues that may not become visible until later in the
implementation. Reusing design patterns helps to prevent subtle issues
that can cause major problems and improves code readability for coders
and architects familiar with the patterns.
Often, people only understand how to apply certain software design
techniques to certain problems. These techniques are difficult to apply to
a broader range of problems. Design patterns provide general solutions,
documented in a format that doesn't require specifics tied to a particular
problem.
In addition, patterns allow developers to communicate using well-
known, well understood names for software interactions. Common design
patterns can be improved over time, making them more robust than ad-
hoc designs.
6 | Overview
Creational patterns
This design patterns is all about class instantiation. This pattern can be
further divided into class-creation patterns and object-creational patterns.
While class-creation patterns use inheritance effectively in the
instantiation process, object-creation patterns use delegation effectively
to get the job done.
Abstract Factory 10
Creates an instance of several families of classes
Builder 24
Separates object construction from its representation
Factory Method 51
Creates an instance of several derived classes
Object Pool 80
Avoid expensive acquisition and release of resources by recycling
objects that are no longer in use
Prototype 90
A fully initialized instance to be copied or cloned
Singleton 97
A class of which only a single instance can exist
Overview | 7
Structural patterns
This design patterns is all about Class and Object composition.
Structural class-creation patterns use inheritance to compose interfaces.
Structural object-patterns define ways to compose objects to obtain new
functionality.
Adapter 14
Match interfaces of different classes
Bridge 18
Separates an object’s interface from its implementation
Composite 36
A tree structure of simple and composite objects
Decorator 41
Add responsibilities to objects dynamically
Façade 47
A single class that represents an entire subsystem
Flyweight 56
A fine-grained instance used for efficient sharing
Private Class Data 88
Restricts accessor/mutator access
Proxy 94
An object representing another object
8 | Overview
Behavioral patterns
This design patterns is all about Class's objects communication.
Behavioral patterns are those patterns that are most specifically
concerned with communication between objects.
Chain of responsibility 28
A way of passing a request between a chain of objects
Command 32
Encapsulate a command request as an object
Interpreter 60
A way to include language elements in a program
Iterator 63
Sequentially access the elements of a collection
Mediator 67
Defines simplified communication between classes
Memento 72
Capture and restore an object's internal state
Null Object 75
Designed to act as a default value of an object
Observer 84
A way of notifying change to a number of classes
State 101
Alter an object's behavior when its state changes
Strategy 105
Encapsulates an algorithm inside a class
Template method 109
Defer the exact steps of an algorithm to a subclass
Visitor 113
Defines a new operation to a class without change
Overview | 9
Abstract Factory
Intent
• Provide an interface for creating families of related or dependent
objects without specifying their concrete classes.
• A hierarchy that encapsulates: many possible "platforms", and the
construction of a suite of "products".
• The new operator considered harmful.
Problem
If an application is to be portable, it needs to encapsulate platform
dependencies. These "platforms" might include: windowing system,
operating system, database, etc. Too often, this encapsulatation is not
engineered in advance, and lots of #ifdef case statements with
options for all currently supported platforms begin to procreate like
rabbits throughout the code.
Discussion
Provide a level of indirection that abstracts the creation of families
of related or dependent objects without directly specifying their
concrete classes. The "factory" object has the responsibility for
providing creation services for the entire platform family. Clients
never create platform objects directly, they ask the factory to do that
for them.
This mechanism makes exchanging product families easy because
the specific class of the factory object appears only once in the
application - where it is instantiated. The application can wholesale
replace the entire family of products simply by instantiating a different
concrete instance of the abstract factory.
Because the service provided by the factory object is so pervasive,
it is routinely implemented as a Singleton.
10 | Abstract Factory