Design Patterns

Supada Laosooksathit
101-87-765
October 18, 2008

Definition
A design pattern is a general reusable solution to a standard reoccurring problem in software design. [1] A
design pattern is a description to template for how to solve a problem that can be used in many different
situations. Object-oriented design patterns typically show relationships and interactions between classes
or objects, without specifying the final application classes or objects that are involved. Not all software
patterns are design patterns. Design patterns deal specifically with problems at the level of software design.
Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative
scopes. [2]

History
Design patterns have originated as an architectural concept by Christopher Alexander, a civil engineer
who wrote about his experience in solving design issues as they related to buildings and towns. [2, 3] He
documented and published the wisdom and experience he gained from his work so that others could benefit.
About 15 years ago, software professionals began to incorporate Alexander’s principles into the creation of
early design pattern documentation as a guide to novice developers. [3]
In 1987, Kent Beck and Ward Cunningham presented the idea of applying patterns to programming
at the OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference. In the
following years, Beck, Cunningham and others followed up on this work. Since then, many papers and
presentations have appeared. [2]
Design patterns gained popularity in computer science after the book Design Patterns: Elements of
Reusable Object-Oriented Software was published in 1994 by Eric Gamma, Richard Helm, Ralph Johnson,
and John Vlissides. (They are often refered to as the Gang of Four, or GoF.) [2, 4]

Pratice and Uses

Design patterns can speed up the development process by providing a way to solve issues related to soft-
ware development using a proven solution. They provide general solutions documented in a typical format.
Reusing design patterns also helps to prevent subtle issues that can cause major problems, and improves
code readability for coders and architects familiar with the patterns. [3, 5] Design patterns can make com-
munication between designers more efficient with well-known, well-understood names of software interations.
[3, 5]

1
Classification
Design patterns are classified into the following categories.

Creational Patterns
Creational patterns are a best way in which class and object can be instantiated. [5, 6] This pattern can
be divided into class-creation patterns which use interitance effectively in the instantiation process and
object-creational patterns which use delegation effectively to get the job done. [5]
• Abstract Factory
An abstract factory pattern provides an interface for creating families of related or dependent objects
without specifying their concrete classes. [2, 5] It provides a way to encapsulate a group of individual
factories that have a common theme. The client software would create a concrete implementation
of the abstract factory and use the generic interfaces to create the concrete objects that are part of
the theme. The names of actual implementing classes are not needed to be known at the client side.
Because this pattern separates the details of implementation of a set of objects from its general usage,
the implementation can be changed from one factory to another. [2, 6]
• Factory Method
A factory method pattern define an interface for creating objects, whose subclasses can override to
specify the derived type of product that will be created. It lets subclasses decide which class to
instantiate. [2, 5]
• Builder
A builder pattern intends to separate the construction of a complex object from its representation so
that the same construction process can create different representations. It is used to build products
in accordance to the Composite Pattern, a Structure Pattern. It parse a complex representation and
create on of several targets. [2, 5]
• Object Pool
An object pool is a set of initialised objects that are kept ready to use, rather than allocated and
destroyed on demand. A client of the pool will request an object from the pool and perform operations
on the returned object. When the client has finished with an object, it returns the object to the pool,
rather than destroying it. It is a specific type of factory object. Object pooling is most effective in
situations where the cost of initializing a class instance is high, the rate of instantiation of a class is
high, and the number of instances in use at any one time is low. [2, 5]
• Prototype
A prototype pattern is used to create a clone of an object to avoid creation a new one when the cost of
creating a new object is large and creation is resource intensive. To implement the pattern, declare an
abstrat base class that specifies a pure virtual clone() method and the client calls the clone() method
on the prototype instead of invokeing the new operator. [2, 6]
• Singleton
A singleton pattern is used to restrict instantiation of a class to one object. This concept is generalized
to restrict the instance to specific number of objects and to systems that operate more efficiently when
only one or a few objects exist. A ”singleton” simply refers to an object without copies or that is not
used as the prototype for any other object. [2]

2
Structural Patterns
Structural Patterns describe classes and objects composition. The difference between class patterns and
object patterns is that class patterns describe how inheritance can be used to compose interfaces. Object
patterns, on the other hand,s describe how objects can be used to obtain new functionality. [5, 6]

• Adapter
An adapter design pattern converts the in interface of a class into another interface that clients expect.
It allows classes work together that normally could not because of incompatible interfaces by wraping an
existing class with a new interface. [2, 5] The adapter pattern can be implemented by both inheritance
and by composition. [6]
• Bridge
A bridge pattern is used to separate out the interface from its implementation so that both can vary
independently. [6] The bridge uses encapsulation, aggregation, and can use inheritance to separate
responsibilities into different classes. The bridge pattern is useful when not only the class itself varies
often but also what the class does. The class itself can be thought of as the implementation and what
the class can do as the abstraction. [2]
• Composite
A composite pattern allows a group of objects to be composed into tree structures to represent part-
whole hierarchies. It allows clients treat individual objects and compositions uniformly. [2, 5, 6]

• Decorator
A decorator pattern attaches new or additional behavior and functionality to an object dynamically.
It provides a flexible alternative to subclassing for extending functionality at runtime by adding a new
decorator class that wraps the original class. [2, 5] Since the decorator is an object created at runtime,
it can be combined on a per-use basis and avoid the problem of some object-oriented programming
languages that classes cannot be created at runtime. [2] The decorator and adapter patterns are similar.
An adapter seems to decorate the classes and convert the interface of one or more classes to suit the
interface of the client program. The intent of decorator is to add behavior and functionality to some
of the objects. [6]
• Facade
A facade pattern is an object that provides a simplified interface to a large body of code. It is used to
hides the complexities of the system and provides an interface to the client from where the client can
access the system. [2, 6] A facade pattern can make a software library easier to use and understand
and allowing more flexibility in developing the system by reducing dependencies of outside code on the
inner code. [2]
• Flyweight
A flyweight pattern describes how to share objects to avoid creating a large number of object instances
to represent the entire system. [6] It allows the share objects’ use at fine granularities without pro-
hibitive cost. Each flyweight object consists of the state-dependent part, called extrinsic part, and
the state-independent part, called intrinsic part. The intrinsic state is stored in the flyweight object
while the extrinsic state is stored or computed by client objects and passed to the flyweight when it’s
operation are invoked. [5]

3
 • Proxy
A proxy pattern provides a surrogate or place holder for another object to control access to it by using
an extra level of indirection to support distributed, controled, or intelligent access. The proxy will add
a wrapper and delegation to protect the real component from undue complexity. [5]

Behavioral Patterns
Behavioral patterns are those patterns that are most specifically concerned with interactions between class’s
objects. [5]
• Chain of Responsibility
A chain of responsibility pattern decouples the sender of the request to its receiver by giving more than
one object a chance to handle the request. Chain the receiving objects and pass the request along the
chain until an object handles it. The chain of responsibility pattern launch and leave requests with a
single processing pipeline that contains many possible handlers. [5]
• Command
A command pattern encapsulates a request as an object, thereby letting you parameterize clients with
defferent requests, queue or log requests, and support undoable operations. [5] With this pattern,
objects is used to represent actions.[2] The client invokes a particular module using a command and
passes a request. This request gets propagated as a command. The command request maps to particular
modules. According to the command, a module is invoked. [6]
• Interpreter
An interpreter pattern defines a grammatical representation for a language along with an interpreter
that uses the representation to interpret sentences in the language. It maps a domain to a language,
the language to grammar, and the grammar to a hierarchical design. [5, 6]
• Iterator
An iterator patterns provide a way to access the elements of an aggregate object sequentially without
exposing its underlying representation. [5] The benefits of Iterator are about their strength to provide a
common interface for iterating through collections without bothering about underlying implementation.
It should be implemented as an interface. By doing this, it is able to be implemented in the easy way
for the user to return data.[6]
• Mediator
A mediator pattern defines an object that encapsulates how a set of objects interact. This pattern
deals with the complexity which comes in the coding when number of classes increase and promotes
loose coupling by keeping objects from referring to each other explicitly, and allows their interaction
be varied independently. [5, 6]
• Memento
A memento Pattern provides the ability to restore an object to its previous state. [2] This pattern
capture and externalize an internal state of an object so that the object can be returned to this state
later. [5] The memento pattern is used by two objects: the originator and a caretaker. The originator
is some object that has an internal state. The caretaker is going to do something to the originator,
but wants to be able to undo the change. The caretaker first asks the originator for a memento object.
Then it does whatever operation or sequence of operations that it was going to do. To roll back to the
state before the operations, it returns the memento object to the originator. [2]

4
• Observer
An observer pattern defines a one-to-many dependency between objects so that when one object changes
state, all its dependents are notified and updated automaticlly. [5] This process is usually done by
calling one of their methods. It is mainly used to implement distributed event handling systems. [2]
• State
A state pattern allows an object to alter its behavior when its internal state changes. The object will
appear to change its class. [5] An object’s behavior change is represented by its member classes, which
share the same super class. [7]
• Strategy
A strategy pattern defines a family of algorithms, encapsulate each one, and make them interchangeable.
This pattern lets the algorithm vary independently from the clients that use it and groups several
algorithms in a single module to provide alternatives. [5, 7] It consists of decoupling an algorithm from
its host, and encapsulating the algorithm into a separate class. More simply put, an object and its
behaviour are separated and put into two different classes. This allows you to switch the algorithm
that you are using at any time. [8]
• Template Method
A template method is used to set up the skeleton of an algorithm in an operation and deferring some
steps to client subclasses. [5] This way, subclasses can override parts of the algorithm without changing
its overall structure. It is useful for separating the variant and the invariant behaviour, minimizing
the amount of code to be written. The invariant behaviour is placed in the template and then any
subclasses that inherit it can override the abstract methods and implement the specifics needed in that
context. [8]
• Visitor
A visitor pattern defines a new operation to be performed on the elements of an object structure
without changing the classes of the elements on which it operates. [7] Each node in the data structure
”accepts” a Visitor, which sends a message to the Visitor which includes the node’s class. The visitor
will then execute its algorithm for that element. This process is known as ”Double Dispatching.” The
node makes a call to the Visitor, passing itself in, and the Visitor executes its algorithm on the node.
In Double Dispatching, the call made depends upon the type of the Visitor and of the Host (data
structure node), not just of one component.[8]

5
References
[1] Douglas C. Schmidt, Ralph E. Johnson, and Mohamed Fayad. CACM Guest Editorial on Software
Patterns. online. http://www.cs.wustl.edu/˜schmidt/CACM-editorial.html.
[2] Design pattern (computer science). online. http://en.wikipedia.org/wiki/Design pattern (computer science).
[3] James Maioriello. What Are Design Patterns and Do I Need Them? online.
http://www.developer.com/design/article.php/1474561.
[4] Design Patterns. online. http://en.wikipedia.org/wiki/Design Patterns.
[5] Design patterns. online. http://sourcemaking.com/design patterns.
[6] Prashant Satarkar. JAVA DESIGN PATTERNS. online.
http://www.allapplabs.com/java design patterns/java design patterns.htm.
[7] Design Patterns — JavaCamp.org. online. http://www.javacamp.org/designPattern/.

[8] Design Patterns. online. http://exciton.cs.rice.edu/javaresources/DesignPatterns.