In software engineering, a design pattern is a general reusable solution to a commonly

occurring problem in software design. A design pattern is not 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. Object-oriented design patterns typically show
relationships and interactions between classes or objects, without specifying the final
application classes or objects that are involved.
Design patterns reside in the domain of modules and interconnections. At a higher level there
are architectural patterns that are larger in scope, usually describing an overall pattern
followed by an entire system.
There are many types of design patterns: Structural patterns address concerns related to the
high-level structure of an application being developed. Computational patterns address
concerns related to the identification of key computations. Algorithm strategy patterns
address concerns related to high level strategies that describe how to exploit application
characteristic on a computation platform. Implementation strategy patterns address
concerns related to the realization of the source code to support how the program itself is
organized and the common data structures specific to parallel programming. Execution
patterns address concerns related to the support of the execution of an application, including
the strategies in executing streams of tasks and building blocks to support the synchronization
between tasks.
Becoming a chess master
First learn rules and physical requirements
– e.g., names of pieces, legal movements, chess
board geometry and orientation, etc.
• Then learn principles
– e.g, relative value of certain pieces, strategic value
of center squares, power of a threat, etc.
• To become a Master of chess, one must
study the games of other masters
– These games contain patterns that must be
understood, memorized, and applied repeatedly.
• There are hundreds of these patterns
Becoming a Software Design master
First learn rules
– e.g., algorithms, data structures, and languages of
software.
• Then learn principles
– e.g., structured programming, modular
programming, object-oriented programming, etc.
• To become a Master of SW design, one must
study the designs of other masters
– These designs contain patterns that must be
understood, memorized, and applied repeatedly.
• There are hundreds of these patterns
Each design pattern has four essential elements:

1. Name - This is what the pattern will be referred to as. Each design pattern will have a
name used for association of the design pattern in software design and architectural
discussions..
2. Problem - This describes the scope of the problem the design pattern is solving. The
problem definition is used in determining potential pattern application.
3. Solution - This describes the structure of the elements that make up the pattern. This
is typically given in the form of a UML class diagram and/or object diagram.
4. Consequences - There are always benefits and drawbacks for any design decision.
Consequences of a design pattern will concern space and time trade-offs.

In addition, all patterns can be categorized by their intent, or purpose. This book covers three
main groups of patterns:In software engineering, creational design patterns are design
patterns that deal with object creation mechanisms, trying to create objects in a manner
suitable to the situation. The basic form of object creation could result in design problems or
added complexity to the design. Creational design patterns solve this problem by somehow
controlling this object creation.

Abstract Factory
Creates an instance of several families of classes

Builder
Separates object construction from its representation

Factory Method
Creates an instance of several derived classes

Object Pool
Avoid expensive acquisition and release of resources by recycling objects that are no longer in use

Prototype
A fully initialized instance to be copied or cloned

Singleton
A class of which only a single instance can exist.
Structural patterns
In Software Engineering, Structural Design Patterns are Design Patterns that ease the design
by identifying a simple way to realize relationships between entities.

 Adapter
Match interfaces of different classes
 Bridge
Separates an object's interface from its implementation
 Composite
A tree structure of simple and composite objects
 Decorator
Add responsibilities to objects dynamically
 Facade
A single class that represents an entire subsystem
 Flyweight
A fine-grained instance used for efficient sharing
 Private Class Data
Restricts accessor/mutator access
 Proxy
An object representing another object
 

Behavioral patterns
In software engineering, behavioral design patterns are design patterns that identify common
communication patterns between objects and realize these patterns. By doing so, these
patterns increase flexibility in carrying out this communication.

Chain of responsibility
A way of passing a request between a chain of objects

Command
Encapsulate a command request as an object

Interpreter
A way to include language elements in a program

Iterator
Sequentially access the elements of a collection

Mediator
Defines simplified communication between classes

Memento
Capture and restore an object's internal state

Null Object
Designed to act as a default value of an object

Observer
A way of notifying change to a number of classes

State
Alter an object's behavior when its state changes

Strategy
Encapsulates an algorithm inside a class

Template method
Defer the exact steps of an algorithm to a subclass
Visitor
Defines a new operation to a class without change.

Benefits of Design Patterns

 Inspiration
o Patterns don't provide solutions, they inspire solutions.
o Patterns explicitly capture expert knowledge and design tradeoffs and make this
expertise widely available.
o Ease the transition to object-oriented technology.
 Patterns improve developer communication
o Pattern names form a vocabulary.
 Help document the architecture of a system
o Enhance understanding.
 Design patterns enable large-scale reuse of software architectures

Drawbacks of Design Patterns

 Patterns do not lead to direct code reuse.
 Patterns are deceptively simple.
 Teams may suffer from patterns overload.
 Integrating patterns into a software development process is a human-intensive activity.
 Where Design Patterns Are Used
 Object-Oriented Programming Languages:
 more amenable to implementing design patterns
 Procedural languages: need to define
 Inheritance,
 Polymorphism and
 Encapsulation
For Effective Design patterns
 Do not recast everything as a pattern
 – Instead, develop strategic domain patterns and reuse existing tactical patterns
 Institutionalize rewards for developing patterns
 Directly involve pattern authors with application developers and domain
experts
 Clearly document when patterns apply and do not apply
 Manage expectations carefully.