Analysis and Design Tools
Home Page.....
UMLOOP'sDesign Patterns
Design Patterns ASP.NetC#   MFCJAVAJ2EE   EJB
The term “design patterns” sounds a bit formal to the uninitiated and
can be somewhat off-putting when you first encounter it. But, in fact, design
patterns are just convenient ways of reusing object-oriented code between
projects and between programmers. The idea behind design patterns is
simple-- write down and catalog common interactions between objects that
programmers have frequently found useful.
The field of design patterns goes back at least to the early 1980s. At
that time, Smalltalk was the most common OO language and C++ was still in
its infancy. At that time, structured programming was a commonly-used
phrased and OO programming was not yet as widely supported. The idea of
programming frameworks was popular however, and as frameworks
developed, some of what we now called design patterns began to emerge.
One of the frequently cited frameworks was the Model-View-
Controller framework for Smalltalk [Krasner and Pope, 1988], which divided
the user interface problem into three parts. The parts were referred to as a
data model which contain the computational parts of the program, the view,
which presented the user interface, and the controller, which interacted
between the user and the view.
Each of these aspects of the problem is a separate object and each has
its own rules for managing its data. Communication between the user, the
GUI and the data should be carefully controlled and this separation of
functions accomplished that very nicely. Three objects talking to each other
using this restrained set of connections is an example of a powerful design
Controller View
In other words, design patterns describe how objects communicate
without become entangled in each other’s data models and methods. Keeping
this separation has always been an objective of good OO programming, and if
you have been trying to keep objects minding their own business, you are
probably using some of the common design patterns already. Interestingly
enough, the MVC pattern has resurfaced now and we find it used in Java 1.2
as part of the Java Foundation Classes (JFC, or the “Swing” components).
Design patterns began to be recognized more formally in the early
1990s by Helm (1990) and Erich Gamma (1992), who described patterns
incorporated in the GUI application framework, ET++. The culmination of
these discussions and a number of technical meetings was the publication of
the parent book in this series, Design Patterns -- Elements of Reusable
Software, by Gamma, Helm, Johnson and Vlissides.(1995). This book,
commonly referred to as the Gang of Four or “GoF” book, has had a powerful
impact on those seeking to understand how to use design patterns and has
become an all-time best seller. We will refer to this groundbreaking book as
Design Patterns, throughout this book and The Design Patterns Smalltalk
Companion (Alpert, Brown and Woolf, 1998) as the Smalltalk Companion.
Defining Design Patterns
We all talk about the way we do things in our everyday work,
hobbies and home life and recognize repeating patterns all the time.
· Sticky buns are like dinner rolls, but I add brown sugar and nut filling to
· Her front garden is like mine, but, in mine I use astilbe.
· This end table is constructed like that one, but in this one, the doors
replace drawers.
We see the same thing in programming, when we tell a colleague
how we accomplished a tricky bit of programming so he doesn’t have to
recreate it from scratch. We simply recognize effective ways for objects to
communicate while maintaining their own separate existences.
Some useful definitions of design patterns have emerged as the
literature in his field has expanded:
· “Design patterns are recurring solutions to design problems you see over
et. al., 1998).
· “Design patterns constitute a set of rules describing how to accomplish
certain tasks in the realm of software development.” (Pree, 1994)
· “Design patterns focus more on reuse of recurring architectural design
themes, while frameworks focus on detailed design… and
implementation.” (Coplien & Schmidt, 1995).
· “A pattern addresses a recurring design problem that arises in specific
design situations and presents a solution to it” (Buschmann, et. al. 1996)
· “Patterns identify and specify abstractions that are above the level of
single classes and instances, or of components.” (Gamma, et al., 1993)
But while it is helpful to draw analogies to architecture, cabinet
making and logic, design patterns are not just about the design of objects, but
about the communication between objects. In fact, we sometimes think of
them as communication patterns. It is the design of simple, but elegant,
methods of communication that makes many design patterns so important.
Design patterns can exist at many levels from very low level specific
solutions to broadly generalized system issues. There are now in fact
hundreds of patterns in the literature. They have been discussed in articles
and at conferences of all levels of granularity. Some are examples which have
wide applicability and a few (Kurata, 1998) solve but a single problem.
It has become apparent that you don’t just write a design pattern off
the top of your head. In fact, most such patterns are discovered rather than
written. The process of looking for these patterns is called “pattern mining,”
and is worthy of a book of its own.
The 23 design patterns selected for inclusion in the original Design
Patterns book were ones which had several known applications and which
were on a middle level of generality, where they could easily cross
application areas and encompass several objects.
The authors divided these patterns into three types creational,
structural and behavioral.
· Creational patterns are ones that create objects for you, rather than
having you instantiate objects directly. This gives your program more
flexibility in deciding which objects need to be created for a given case.
· Structural patterns help you compose groups of objects into larger
structures, such as complex user interfaces or accounting data.
· Behavioral patterns help you define the communication between objects
in your system and how the flow is controlled in a complex program.
We’ll be looking at Java versions of these patterns in the chapters that
This Book and its Parentage
Design Patterns is a catalog of 23 generally useful patterns for
writing object-oriented software. It is written as a catalog with short examples
and substantial discussions of how the patterns can be constructed and
applied. Most of its examples are in C++, with a few in Smalltalk. The
Smalltalk Companion (Alpert, 1998) follows a similar approach, but with
somewhat longer examples, all in Smalltalk. Further, the authors present
some additional very useful advice on implementing and using these patterns.
This book takes a somewhat different approach; we provide at least
one complete, visual Java program for each of the 23 patterns. This way you
can not only examine the code snippets we provide, but run, edit and modify
the complete working programs on the accompanying CD-ROM. You’ll find
a list of all the programs on the CD-ROM in Appendix A.
The Learning Process
We have found learning Design patterns is a multiple step process.
1. Acceptance
2. Recognition
3. Internalization
First, you accept the premise that design patterns are important in your work.
Then, you recognize that you need to read about design patterns in order to
know when you might use them. Finally, you internalize the patterns in
sufficient detail that you know which ones might help you solve a given
design problem.
For some lucky people, design patterns are obvious tools and they grasp their
essential utility just by reading summaries of the patterns. For many of the
rest of us, there is a slow induction period after we’ve read about a pattern
followed by the proverbial “Aha!” when we see how we can apply them in
our work. This book helps to take you to that final stage of internalization by
providing complete, working programs that you can try out for yourself.
The examples in Design Patterns are brief, and are in C++ or in some
cases, Smalltalk. If you are working in another language it is helpful to have
the pattern examples in your language of choice. This book attempts to fill
that need for Java programmers.
A set of Java examples takes on a form that is a little different than in
C++, because Java is more strict in its application of OO precepts -- you can’t
have global variables, data structures or pointers. In addition, we’ll see that
the Java interfaces and abstract classes are a major contributor to how we
build Java design patterns.
Studying Design Patterns
There are several alternate ways to become familiar with these
patterns. In each approach, you should read this book and the parent Design
Patterns book in one order or the other. We also strongly urge you to read the
Smalltalk Companion for completeness, since it provides an alternate
description of each of the patterns. Finally, there are a number of web sites on
learning and discussing Design Patterns for you to peruse.
Notes on Object Oriented Approaches
The fundamental reason for using varies design patterns is to keep
classes separated and prevent them from having to know too much about one
another. There are a number of strategies that OO programmers use to
achieve this separation, among them encapsulation and inheritance.
Nearly all languages that have OO capabilities support inheritance. A
class that inherits from a parent class has access to all of the methods of that
parent class. It also has access to all of its non-private variables. However, by
starting your inheritance hierarchy with a complete, working class you may
be unduly restricting yourself as well as carrying along specific method
implementation baggage. Instead, Design Patterns suggests that you always
Program to an interface and not to an implementation.
Purring this more succinctly, you should define the top of any class hierarchy
with an abstract class, which implements no methods, but simply defines the
methods that class will support. Then, in all of your derived classes you have
more freedom to implement these methods as most suits your purposes.
The other major concept you should recognize is that of object composition.
This is simply the construction of objects that contain others: encapsulation of
several objects inside another one. While many beginning OO programmers
use inheritance to solve every problem, as you begin to write more elaborate
programs, the merits of object composition become apparent. Your new
object can have the interface that is best for what you want to accomplish
without having all the methods of the parent classes. Thus, the second major
precept suggested by Design Patterns is
Favor object composition over inheritance.
At first this seems contrary to the customs of OO programming, but you will
see any number of cases among the design patterns where we find that
inclusion of one or more objects inside another is the preferred method.
The Java Foundation Classes
The Java Foundation Classes (JFC) which were introduced after Java
1.1 and incorporated into Java 1.2 are a critical part of writing good Java
programs. These were also known during development as the “Swing” classes
and still are informally referred to that way. They provide easy ways to write
very professional-looking user interfaces and allow you to vary the look and
feel of your interface to match the platform your program is running on.
Further, these classes themselves utilize a number of the basic design patterns
and thus make extremely good examples for study.
Nearly all of the example programs in this book use the JFC to
produce the interfaces you see in the example code. Since not everyone may
be familiar with these classes, and since we are going to build some basic
classes from the JFC to use throughout our examples, we take a short break
after introducing the creational patterns and spend a chapter introducing the
JFC. While the chapter is not a complete tutorial in every aspect of the JFC, it
does introduce the most useful interface controls and shows how to use them.
Many of the examples do require that the JFC libraries are installed,
and we describe briefly what Jar files you need in this chapter as well.
Java Design Patterns
Each of the 23 design patterns in Design Patterns is discussed in the
chapters that follow, along with at least one working program example for
that pattern. The authors of Design Patterns have suggested that every
pattern start with an abstract class and that you derive concrete working
classes from that abstraction. We have only followed that suggestion in cases
where there may be several examples of a pattern within a program. In other
cases, we start right in with a concrete class, since the abstract class only
makes the explanation more involved and adds little to the elegance of the
James W. Cooper
Wilton, Connecticut
Nantucket, Massachusetts
Creational Patterns
All of the creational patterns deal with the best way to create
instances of objects. This is important because your program should not
depend on how objects are created and arranged. In Java, of course, the
simplest way to create an instance of an object is by using the new operator.
Fred = new Fred(); //instance of Fred class
However, this really amounts to hard coding, depending on how you
create the object within your program. In many cases, the exact nature of the
object that is created could vary with the needs of the program and
abstracting the creation process into a special “creator” class can make your
program more flexible and general.
The Factory Method provides a simple decision making class that
returns one of several possible subclasses of an abstract base class depending
on the data that are provided.
The Abstract Factory Method provides an interface to create and
return one of several families of related objects.
The Builder Pattern separates the construction of a complex object
from its representation, so that several different representations can be created
depending on the needs of the program.
The Prototype Pattern starts with an initialized and instantiated
class and copies or clones it to make new instances rather than creating new
The Singleton Pattern is a class of which there can be no more than
one instance. It provides a single global point of access to that instance.
One type of pattern that we see again and again in OO programs is
the Factory pattern or class. A Factory pattern is one that returns an instance
of one of several possible classes depending on the data provided to it.
Usually all of the classes it returns have a common parent class and common
methods, but each of them performs a task differently and is optimized for
different kinds of data.
How a Factory Works
To understand a Factory pattern, let’s look at the Factory diagram
xy xz
In this figure, x is a base class and classes xy and xz are derived from
it. The Factory is a class that decides which of these subclasses to return
depending on the arguments you give it. On the right, we define a getClass
method to be one that passes in some value abc, and that returns some
instance of the class x. Which one it returns doesn't matter to the programmer
since they all have the same methods, but different implementations. How it
decides which one to return is entirely up to the factory. It could be some very
complex function but it is often quite simple.
Sample Code
Let's consider a simple case where we could use a Factory class.
Suppose we have an entry form and we want to allow the user to enter his
name either as “firstname lastname” or as “lastname, firstname”. We’ll make
the further simplifying assumption that we will always be able to decide the
name order by whether there is a comma between the last and first name.
This is a pretty simple sort of decision to make, and you could make
it with a simple if statement in a single class, but let’s use it here to illustrate
how a factory works and what it can produce. We’ll start by defining a simple
base class that takes a String and splits it (somehow) into two names:
class Namer {
//a simple class to take a string apart into two names
protected String last; //store last name here
protected String first; //store first name here
public String getFirst() {
return first; //return first name
public String getLast() {
return last; //return last name
In this base class we don’t actually do anything, but we do provide
implementations of the getFirst and getLast methods. We’ll store the split
first and last names in the Strings first and last, and, since the derived classes
will need access to these variables, we’ll make them protected.
The Two Derived Classes
Now we can write two very simple derived classes that split the name
into two parts in the constructor. In the FirstFirst class, we assume that
everything before the last space is part of the first name:
class FirstFirst extends Namer { //split first last
public FirstFirst(String s) {
int i = s.lastIndexOf(" "); //find sep space
if (i > 0) {
//left is first name
first = s.substring(0, i).trim();
//right is last name
last =s.substring(i+1).trim();
else {
first = “”; // put all in last name
last = s; // if no space
And, in the LastFirst class, we assume that a comma delimits the last
name. In both classes, we also provide error recovery in case the space or
comma does not exist.
class LastFirst extends Namer { //split last, first
public LastFirst(String s) {
int i = s.indexOf(","); //find comma
if (i > 0) {
//left is last name
last = s.substring(0, i).trim();
//right is first name
first = s.substring(i + 1).trim();
else {
last = s; // put all in last name
first = ""; // if no comma
Building the Factory
Now our Factory class is extremely simple. We just test for the
existence of a comma and then return an instance of one class or the other:
class NameFactory {
//returns an instance of LastFirst or FirstFirst
//depending on whether a comma is found
public Namer getNamer(String entry) {
int i = entry.indexOf(","); //comma determines name
if (i>0)
return new LastFirst(entry); //return one class
return new FirstFirst(entry); //or the other
Using the Factory
Let’s see how we put this together.
We have constructed a simple Java user interface that allows you to
enter the names in either order and see the two names separately displayed.
You can see this program below.
You type in a name and then click on the Compute button, and the
divided name appears in the text fields below. The crux of this program is the
compute method that fetches the text, obtains an instance of a Namer class
and displays the results.
In our constructor for the program, we initialize an instance of the
factory class with
NameFactory nfactory = new NameFactory();
Then, when we process the button action event, we call the
computeName method, which calls the getNamer factory method and then
calls the first and last name methods of the class instance it returns:
private void computeName() {
//send the text to the factory and get a class back
namer = nfactory.getNamer(entryField.getText());
//compute the first and last names
//using the returned class
And that’s the fundamental principle of Factory patterns. You create
an abstraction which decides which of several possible classes to return and
returns one. Then you call the methods of that class instance without ever
knowing which derived class you are actually using. This approach keeps the
issues of data dependence separated from the classes’ useful methods. You
will find the complete code for on the example CD-ROM.
Factory Patterns in Math Computation
Most people who use Factory patterns tend to think of them as tools
for simplifying tangled programming classes. But it is perfectly possible to
use them in programs that simply perform mathematical computations. For
example, in the Fast Fourier Transform (FFT), you evaluate the following
four equations repeatedly for a large number of point pairs over many passes
through the array you are transforming. Because of the way the graphs of
these computations are drawn, these equations constitute one instance of the
FFT “butterfly.” These are shown as Equations 1--4.
However, there are a number of times during each pass through the
data where the angle y is zero. In this case, your complex math evaluation
reduces to Equations (5-8):
So it is not unreasonable to package this computation in a couple of
classes doing the simple or the expensive computation depending on the
angle y. We’ll start by creating a Complex class that allows us to manipulate
real and imaginary number pairs:
class Complex {
float real;
float imag;
It also will have appropriate get and set functions.
sin( ) cos( )
sin( ) cos( )
cos( ) sin( )
cos( ) sin( )
1 2 2
1 2 2
1 2 2
1 2 2
I I R y I y
I I R y I y
R R R y I y
R R R y I y
= - -
= + +
= - +
= + -
1 2
1 2
1 2
1 2
= -
= +
= -
= +
Then we’ll create our Butterfly class as an abstract class that we’ll fill
in with specific descendants:
abstract class Butterfly {
float y;
public Butterfly() {
public Butterfly(float angle) {
y = angle;
abstract public void Execute(Complex x, Complex y);
Our two actual classes for carrying out the math are called
addButterfly and trigButterfly. They implement the computations shown in
equations (1--4) and (5--8) above.
class addButterfly extends Butterfly {
float oldr1, oldi1;
public addButterfly(float angle) {
public void Execute(Complex xi, Complex xj) {
oldr1 = xi.getReal();
oldi1 = xi.getImag();
xi.setReal(oldr1 + xj.getReal()); //add and subtract
xj.setReal(oldr1 - xj.getReal());
xi.setImag(oldi1 + xj.getImag());
xj.setImag(oldi1 - xj.getImag());
and for the trigonometic version:
class trigButterfly extends Butterfly {
float y;
float oldr1, oldi1;
float cosy, siny;
float r2cosy, r2siny, i2cosy, i2siny;
public trigButterfly(float angle) {
y = angle;
cosy = (float) Math.cos(y); //precompute sine and cosine
siny = (float)Math.sin(y);
public void Execute(Complex xi, Complex xj) {
oldr1 = xi.getReal(); //multiply by cos and sin
oldi1 = xi.getImag();
r2cosy = xj.getReal() * cosy;
r2siny = xj.getReal() * siny;
i2cosy = xj.getImag()*cosy;
i2siny = xj.getImag()*siny;
xi.setReal(oldr1 + r2cosy +i2siny); //store sums
xi.setImag(oldi1 - r2siny +i2cosy);
xj.setReal(oldr1 - r2cosy - i2siny);
xj.setImag(oldi1 + r2siny - i2cosy);
Finally, we can make a simple factory class that decides which class
instance to return. Since we are making Butterflies, we’ll call our Factory a
class Cocoon {
public Butterfly getButterfly(float y) {
if (y !=0)
return new trigButterfly(y); //get multiply class
return new addButterfly(y); //get add/sub class
You will find the complete program on the example
When to Use a Factory Pattern
You should consider using a Factory pattern when
· A class can’t anticipate which kind of class of objects it must create.
· A class uses its subclasses to specify which objects it creates.
· You want to localize the knowledge of which class gets created.
There are several similar variations on the factory pattern to
1. The base class is abstract and the pattern must return a complete working
2. The base class contains default methods and is only subclassed for cases
where the default methods are insufficient.
3. Parameters are passed to the factory telling it which of several class types
to return. In this case the classes may share the same method names but
may do something quite different.
Thought Questions
1. Consider a personal checkbook management program like Quicken. It
manages several bank accounts and investments and can handle your bill
paying. Where could you use a Factory pattern in designing a program
like that?
2. Suppose are writing a program to assist homeowners in designing
additions to their houses. What objects might a Factory be used to