DesignPrinciples-and-DesignPatterns

Design
Principles and Patterns

Objective
What principles and patterns are and why they are critical to implement applications
successfully
Understand and apply the principles of object-oriented design
Understand GRASP patterns
Understand important design patterns

Why Design Principles?
All systems change during their life cycle.
Symptoms of Rotting Design
There are 4 primary symptoms that tell us that our designs are rotting.
Rigidity
It is hard to change because every change affects too many other parts of the system
Fragility
When you make a change, unexpected parts of the system break
Immobility
It is hard to reuse in another application because it cannot be separated from the current
application
Viscosity
Design – Engineers usually find more than one way to make change. Some preserve the design and
others do not. When the design preserving methods are harder to employ then the viscosity of the
design is high
Environment – Development environment is slow and inefficient (e.g. compile times are very long)
engineers will be tempted to make changes that don’t force large compiles, even though those
changes are not optimal from design point of view

Changing Requirements
Immediate cause of the degradation of the design
Requirements have been changing in way that the initial design did not anticipate
These changes need to be made quickly, and may be done by others who are not familiar
with the original design philosophy
Changes to the original design somehow violates the original design bit by bit as the changes
continue to pour in, these violations accumulate until malignancy sets in
We, as software engineers should keep in mind that requirements change
If our designs are failing due to the constant rain of changing requirements, it is our designs
that are at fault
Find a way to make our design resilient to such changes and protect from rotting
Any application that exhibits these symptoms is suffering from a design that is rotting from
the inside out.
But what causes that rot to take place ?

What kind of changes cause design to rot ?
Dependency Management
Changes that introduce new and unplanned for dependencies
Four symptoms mentioned earlier is either directly, or indirectly caused by improper dependencies
between the modules of the software
It is the dependency architecture that is degrading
In order to forestall the degradation of the dependency architecture, the dependencies between modules
in an application must be managed
This management consists of the creation of dependency firewalls
So what is the solution ?
Object Oriented Design is supplied with principles and techniques for building such firewalls, and
for managing module dependencies.

Design Principles
Software design principles represent a set of guidelines that helps us to avoid
having a bad design as mentioned earlier.

Key Design Principles
SOLID
Is a acronym introduced by Robert C Martin
Stands for five basic principles of object-oriented programming design
Initial Stands for
(acronym)
Concept
S SRP Single Responsibility Principle
O OCP Open Closed Principle
L LSP Liskov Substitution Principle
I ISP Interface Segregation Principle
D DIP Dependency Inversion Principle
Other
Composite Reuse Principle
Law of Demeter

Single Responsibility Principle (SRP)
What
Single responsibility principle states that every object should have a single responsibility
and therefore a single reason to change
A class should have only one reason to change

Example

Example
What happens if a change to the GraphicalApplication causes the Rectangle to change for
some reason?

Conclusion
Single responsibility principle (SRP)
Why
Single Responsibility - increased cohesion
Readability – easier to read as it performs one task
Testability – only one thing to test
Reusability – class is easier to reuse
Easier to code – easier and faster to code in small chunks
Bugs – become easier to track down
One of the simplest of the principles
Hardest to get it right
A good way of separation of responsibilities
Separation of those responsibilities from one another is much of what software design is
really about

Open Close Principle (OCP)
What
The Open Close Principle states that the design and writing of the code should be done in a way
that new functionality should be added with minimum changes in the existing code
Software entities like classes, modules and functions should be open for extension
but closed for modifications.
The design should be done in a way to allow the adding of new functionality as new classes,
keeping as much as possible existing code unchanged

Example

Example
Imagine few months down the line you got tired of drinking only Coke and Pepsi and wants
to add sprite?

Conclusion
Why
Open for extension – behavior of the module/class can be altered to satisfy the changing
requirements
Closed for modification – modules/classes themselves are not allowed to change
Maintainable – module is maintainable as it never needs to change
Reusability – module/class being open for extension, it is highly reusable
Flexible design involves additional time and effort spent for it and it introduce new level
of abstraction increasing the complexity of the code
So this principle should be applied in those area which are most likely to be changed

Liskov’s Substitution Principle (LSP)
What
The LSP states that if a program (User) module is using a Base class, then the reference to the Base class
can be replaced with a Derived class without affecting the functionality of the program module.
Functions that use references to base (Super) classes must be able to use
objects of derived (Sub) classes without knowing it
All derived classes must honour the contracts
of their base classes
ISA = same public behavior
Pre-conditions can only get weaker
Post-conditions can only get stronger

Example
Whether Square is a Rectangle?
class LspTest
{
private static Rectangle getNewRectangle()
{
// it can be an object returned by some factory ...
return new Square();
}
public static void main (String args[])
{
Rectangle r = LspTest.getNewRectangle();
r.setWidth(5);
r.setHeight(10);
// user knows that r it's a rectangle. It assumes that he's able to set the width and height as
for the base class
System.out.println(r.getArea());
// now he's surprised to see that the area is 100 instead of 50.
}
}
Rectangle
+setHeight() : void
+setWidth() : void
Square
+setHeight() : void
+setWidth() : void

Example
What if the minimum period for SpecialCurrentAccount is not satisfied?
The closing of Current Account should check for a balance
greater than zero. If satisfied, proceed to close the account.
The closing of Special Current Account should check for a
balance greater than zero and also that the minimum period for
the account is covered. If satisfied, proceed to close the account.
period
closeAccount() : void

Conclusion
Why
OCP violations - if / else to identify types
Unit tests – Unit tests for the super class would never succeed for the sub class
Strange behavior - Mess being that whenever a subclass instance was passed as parameter
to any method, strange behavior would occur
This principle is just an extension of the Open Close Principle and it means that we must
make sure that new derived classes are extending the base classes without changing their
behavior
Basically wants you to think clearly about the expected behavior and expectations of a
class before you derive new classes from it

Interface Segregation Principle (ISP)
What
The Interface Segregation Principle states that clients should not be forced to implement
interfaces they don't use. Instead of one fat interface many small interfaces are preferred based
on groups of methods, each one serving one sub module.
Make fine grained interfaces that are client specific

Example

Example
What if there is a need to rotate the file data source to a different file once a
certain amount of data has been written to the file?

Conclusion
Why
High cohesion – Keep all related methods together
Low Coupling – Keep dependence of one another to the bare minimum
Fat interfaces – tend to cause a ripple affect to classes who shouldn’t have been affected
in the first place
It produces a flexible design. If we are going to apply it more than is necessary it will result
a code containing a lot of interfaces with single methods, so applying should be done
based on experience and common sense in identifying the areas where extension of code
are more likely to happens in the future.

Dependency Inversion Principle (DIP)
What
Depend on Abstractions. Do not depend on Concrete implementations
Design towards Interfaces/Abstract classes rather its implementations.
Since implementations are more prone to change and offer less flexibility.
High Level Classes --> Abstraction Layer --> Low Level Classes
According to this principle the way of designing a class structure is to start
from high level modules to the low level modules

Example

Example
What if you want your DataWriter object to be able to write to any destination?

Conclusion
Why
Increase loose coupling
Abstract interfaces don't change
Concrete classes implement interfaces
Concrete classes easy to throw away and replace
Increase mobility
Increase isolation
Decrease rigidity
Increase testability
Increase maintainability
This principle can not be applied for every class or every module. If we have a class
functionality that is more likely to remain unchanged in the future there is no need to
apply this principle.

Composite Reuse Principle (CRP)
What
Favor delegation over inheritance as a reuse mechanism
The Composite Reuse Principles focuses on achieving reuse through delegation (or more
appropriately forwarding), instead of defining default behaviors in ancestor classes.

Example
Subclasses of Employee: Manager,
Programmer, Secretary, etc. may want to
override this method to reflect the fact
that some types of employees
(managers) get more generous bonuses
than others
. . . .
Employee
+computeBonus() : Money
Manager
+computeBonus() : Money
What if we wanted to
change the bonus
computation for a
particular employee

Example
What is the problem and Where can we apply CRP ?

Conclusion
Why
This principle relies heavily upon delegation, or more appropriately forwarding.
Composite Reuse Principle helps us comply with the Open Closed Principle.
Composite Reuse Principle is typically used in conjunction with Dependency Inversion, though
this is not a requirement.
This is where Composition is a superior choice. Inheritance ties you to a particular
implementation or forces you to give up the original idea of generalization by having to
constantly override the super-class methods in each sub-class.

Law of Demeter
What
Restrict class interaction in order to minimize coupling among classes
More formally, the Law of Demeter for functions requires that a method M of an object O may
only invoke the methods of the following kinds of objects:
O itself (this)
M's parameters
any objects created/instantiated within M
O's direct component objects
a global variable, accessible by O, in the scope of M
Also called as Principle of Least Knowledge (PLK)
“Each unit should only talk to its friends.” “Don’t talk to strangers

Example
Law of Demeter
An alternative to PLK, or a variation on its implementation, is to obtain a reference to an
object via a method call, with the restriction that any time this is done, the type of the
reference obtained is always an interface data type.

Example
Law of Demeter
What if currentPerson.Account = null ?
currentPerson.Account.Deposit(500)
Account may need to be initialized before it can be accessed Say currentPerson.Account =
null, will throw null reference exception in bad code
In good code, Deposit method can check if null and setup a new one before depositing
Account.Deposit(currentPerson, 500)

Conclusion
Law of Demeter
Why
The advantage of following the Law of Demeter is that the resulting software tends to be
more maintainable and adaptable.
Since objects are less dependent on the internal structure of other objects, object
containers can be changed without reworking their callers.
A disadvantage of the Law of Demeter is that it sometimes requires writing a large
number of small “wrapper” methods to propagate method calls to the components.
The higher the degree of coupling between classes, the higher the odds that any change
you make will break something somewhere else. This tends to create fragile, brittle code.

Why design patterns ?
Developing software is hard, and developing reusable design is even harder
Helps in software quality, reduce the development time and improves the shared
understanding with in development team
Design Pattern = Proven solution to problems for the specific context
How do you master these patterns?
Simple!! learn rules of the language, then principles/best practices, finally study the patterns
used by other masters. Apply these understanding repeatedly in your problem context
There are hundreds of patterns do exist in software industry, one must have maturity of selecting
appropriate pattern for the context. Care must be taken of applying unnecessary pattern ahead
of requirements which would have been solved without it.

Evolution of Patterns
It all started in civil engineering and architecture
Design patterns originated outside the computer industry
Design patterns are discovered as much as created

What is pattern ?
Pattern describes a proven solution to a recurring design problems
Solution to a problem in a given context
A Pattern is common, repeatable solution
Patterns are generic and take many forms
It is advice from previous designers to help designers in new situations
Patterns capture the static and dynamic structure and collaboration among key
participants in software designs
Patterns facilitate reuse of successful software architectures and designs

Design patterns definitions
“A pattern is a proven solution to a problem in a context “
-
“Each pattern describes a problem which occurs over and over again in our environment,
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.”
- By Alexander
“A pattern is a three-part rule, which expresses a relation between a certain context, a
problem, and a solution”
- By Gang of Four (GoF)
(Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides – GoF)

Properties of patterns
Patterns do...
provide common vocabulary
provide “shorthand” for effectively communicating complex principles
help document software architecture
capture essential parts of a design in compact form
show more than one solution
describe software abstractions
Patterns do not...
provide an exact solution
solve all design problems
only apply for object-oriented design

Identifying a pattern
Identify patterns from experience
Look at your past projects
Analyse good performing applications
Identify pattern candidates
Verify the pattern thoroughly

Using design patterns
Understand it completely
Check twice before using
Study carefully the examples for the pattern
Choose names for the pattern participants that are meaningful for
your application
Define the interfaces, components, classes and relationship
Apply the pattern
Be careful of Antipatterns

Antipatterns
Mistakes are documented as Antipatterns
They are exact opposite of patterns

Patterns categorization
Distributed/Large applications
Applications
Class
Architectural Patterns
Design Patterns
GRASP

GRASP Patterns
GRASP stands for General Responsibility Assignment Software Patterns/Principles.
- Craig Larman
Responsibility
“A contract or obligation of a type or class”
Two types of responsibilities
- knowing
- doing
• about private encapsulated data
• about related objects
• things that can derive or calculate
• something itself
• initiating action in other objects
• controlling and coordinating activities in other
objects

GRASP Patterns
Which class, in the general case is responsible?
You want to assign a responsibility to a class
You want to avoid or minimize additional dependencies
You want to maximise cohesion and minimise coupling
You want to increase reuse and decrease maintenance
You want to maximise understand ability
…..etc.

GRASP Patterns
There are nine (09) core patterns/principles
Information Expert
Creator
Controller
Low Coupling
High Cohesion
Polymorphism
Pure Fabrication
Indirection
Protected Variations

Information Expert
Assign a responsibility to the information expert
- the class that has the information necessary to fulfill the responsibility.
The most commonly used pattern
Problem:
What is the most basic principle by which responsibilities are assigned in object-oriented
design?
Solution:
Assign a responsibility to the class that has the information necessary to fulfil the
responsibility.

Example
Information Expert
Who is responsible for knowing the grand total of a sale in a typical Point of Sale application?
Sale
date
time
Sales
LineItem
quantity
Product
Specification
description
price
UPC
Described-
by
*
Contain
s
1.. *

Need all SalesLineItem instances and their subtotals. Only Sale knows this, so Sale is the
information expert.
Example : Answer
Information Expert
Hence
Sale
date
time
total()
:Salet :=total()
Newmethod
But subtotals are needed for each line item (multiply quantity by price). By Expert,
SalesLineItem is expert, knows quantity and has association with ProductSpecification
which knows price.

Example : Answer
Information Expert
Sale
date
time
total()
:Salet := total()
sli:SalesLineItem
SalesLineItem
quantity
subtotal()
2: st :=subtotal()
:Product
Specification
2.1: p := price()
Product
Specification
description
price
UPC
price()Newmethod
SalesLineItem
:SalesLineItem
1*: [foreach]sli :=next()

Information Expert
Hence responsibilities assign to the 3 classes.
Class Responsibility
Sale knows sale total
SalesLineItem knows line item subtotal
ProductSpecification knows product price

Information Expert
Maintain encapsulation of information
Promotes low coupling
Promotes highly cohesive classes
Can cause a class to become excessively complex
Why

Creator
By creator, assign class B responsibility of creating instance of class A if
B aggregates A objects
B contains A objects
B records instances of A objects
B closely uses A objects
B has the initializing data for creating A objects
Who has responsibility to create an object?
Problem:
Assign responsibility for creating a new instance of some class?
Solution:
Determine which class should create instances of a class based on the relationship between
potential creator classes and the class to be instantiated.

Example
Creator
Who is responsible for creating SalesLineItem objects?
Sale
date
time
Sales
LineItem
quantity
Product
Specification
description
price
UPC
Described-
by
*
Contain
s
1.. *
Look for a class that aggregates or contains SalesLineItem objects.

Example
Creator
Creator pattern suggests Sale.
Collaboration diagram is
Sale
date
time
makeLineItem()
total()
:SalemakeLineItem(quantity)
:SalesLineItem
1:create(quantity) Newmethod

Creator
Promotes low coupling by making instances of a class responsible for creating
objects they need to reference
By creating the objects themselves, they avoid being dependent on another
class to create the object for them
Why

Controller
Assign the responsibility for handling a system event message to a class representing one of
these choices:
1. The business or overall organization (a façade controller).
2. The overall "system" (a façade controller).
3. An animate thing in the domain that would perform the work (a role controller).
4. An artificial class (Pure Fabrication representing the use (a use case controller).
The Controller pattern provides guidance for generally acceptable choices.
Problem:
To assign responsibility for handling a system event?
Solution:
If a program receive events from external sources other than its graphical interface, add an
event class to decouple the event source (s) from the objects that actually handle the events.

Example
Controller
System events in Buy Items use case
enterItem()
endSale()
makePayment()
Who has the responsibility for enterItem()?

Example
Controller
By controller, we have 4 choices
The overall system Post
The overall business Store
Someone in the real world
who is active in the task Cashier
An artificial handler of all system
events of a use case BuyItemsHandler
:POSTenterItem(upc,quantity)
:StoreenterItem(upc,quantity)
:CashierenterItem(upc,quantity)
:BuyItemsHandlerenterItem(upc,quantity)
The choice of which one to use will be influenced by other factors such as cohesion and
coupling

Example :
Controller
- presentation layer coupled to problem domain
Object Store
Enter Item End Sale
UPC
Make Payment
Total
Quantity
Tendered Balance
Cashier
:POSTCommand
presses button
onEnterItem()
:Sale
1:makeLineItem(upc,qty)
PresentationLayer
(Commandobject)
DomainLayer
Itisundesirableforapresentation
layerobjectssuchasaJavaappletto
getinvolvedindecidinghowtohandle
domainprocesses.
Businesslogicisembeddedinthe
presentationlayer,whichisnotuseful.
POSTAppletshouldnot
sendthismessage.
Bad design

Example
Controller
- presentation layer decoupled from problem domain
Object Store
Enter Item End Sale
UPC
Make Payment
Total
Quantity
Tendered Balance
:POST
Cashier
:POSTCommand
presses button
onEnterItem()
1:enterItem(upc,qty)
:Sale1.1:makeLineItem(upc,qty)
PresentationLayer
(CommandObject)
DomainLayer
systemeventmessage
controller
Good design

Controller
Using a controller object keeps external event sources and internal event
handlers independent of each other’ type and behavior
The controller objects can become highly coupled and uncohesive with more
responsibilities
Why

Low Coupling
Assign responsibilities so that (unnecessary) coupling remains low.
How to reduce the impact of change ?
Problem:
To support low dependency and increased reuse?
Solution:
Assign responsibilities so that coupling remains low.
Use this principle to alternatives.

Low Coupling
In object oriented languages, common form of coupling from TypeX to TypeY include:
TypeX has an attribute (data member or instance variable) that refers to a TypeY instance, or
TypeY itself
TypeX has a method which references an instance of TypeY, or TypeY itself, by any means.
These typically include a parameter or local variable of type TypeY, or the object returned
from a message being an instance of TypeY
TypeX is a direct or indirect subclass of TypeY
TypeY is an interface, and TypeX implements that interface

Low Coupling
How can we make classes independent of other classes?
Changes are localised
Easier to understand
Easier to reuse
Payment POST Sale
Who has responsibility to create a payment ?

Low Coupling
Two possibilities:
:POST p :Payment
:Sale
makePayment() 1:create()
2: addPayment(p)
1. Post
2. Sale :POST :Sale
:Payment
makePayment() 1:makePayment()
1.1.create()
Low coupling suggests Sale because Sale has to be coupled to Payment anyway (Sale knows its total).
1 Or 2 ?
Example

Low Coupling
Classes are easier to maintain
Easier to reuse
Changes are localized
Why

High Cohesion
Assign responsibilities so that cohesion remains high.
How to keep object focused, understandable, and manageable, and as a side-effect , support
low coupling ?
Problem:
To keep complexity manageable?
Solution:
Assign responsibilities so that cohesion remains high.
Use this principle to alternatives.

High Cohesion
Some examples
Very Low Cohesion: A Class is solely responsible for many things in very different
functional areas
Low Cohesion: A class has sole responsibility for a complex task in one functional area
High Cohesion. A class has moderate responsibilities in one functional area and
collaborates with classes to fulfil tasks

High Cohesion
Example
Who has responsibility to create a payment?
1.Post
:POST p : Payment
:Sale
makePayment() 1: create()
2: addPayment(p)
Looks OK if makePayement considered in isolation, but adding more system operations, Post
would take on more and more responsibilities and become less cohesive.

High Cohesion
Example
Giving responsibility to Sale supports higher cohesion in Post, as well as
low coupling.
:POST :Sale
:Payment
makePayment() 1: makePayment()
1.1.create()

High Cohesion
Classes are easier to maintain
Easier to understand
Often support low coupling
Supports reuse because of fine grained responsibility
Why

Polymorphism
When related alternatives or behaviours vary by type (class), assign responsibility for the
behaviour using polymorphic operations to the types for which the behaviour varies.
Who is responsible when behaviour varies by type ?
Problem:
To handle alternatives based on types?
Solution:
When alternate behaviours are selected based on the type of an object, use polymorphic
method call to select the behaviour, rather than using if statement to test the type.

Polymorphism
Example
By Polymorphism, each
payment should
authorize itself
CreditPayment
authorize()
CheckPayment
authorize()
CashPayment
authorize()
Payment
amount
In the point -of -sale application, who should be responsible for authorising different
kinds of payments?

Polymorphism
Easier and more reliable then using explicit selection logic
Easier to add additional behaviors later on
Increased number classes in a design
May make the code less easier to follow
Why

Pure Fabrication
Assign a highly cohesive set of responsibilities to an artificial or convenience “behaviour”
class that does not represent a problem domain concept–something made up, in order to
support high cohesion, low coupling, and reuse.
Who is responsible when you are desperate, and do not want to violate high cohesion and
low coupling?
Problem:
Not to violate High Cohesion and Low Coupling?
Solution:
Assign a highly cohesive set of responsibilities to an artificial class that does not represent
anything in the problem domain, in order to support high cohesion, low coupling, and reuse.

Pure Fabrication
Example
Suppose, in the point of sale example, that support is needed to save Sale instances in a relational
database. By Expert, there is some justification to assign this responsibility to Sale class.
However.
• The task requires a relatively large number of supporting database-oriented operations
and the Sale class becomes in cohesive.
• The sale class has to be coupled to the relational database increasing its coupling.
• Saving objects in a relational database is a very general task for which many classes need
support. Placing these responsibilities in the Sale class suggests there is going to be poor
reuse or lots of duplication in other classes that do the same thing.

Pure Fabrication
Example
The Sale remains well design, with high cohesion and low coupling
The PersistentStorageBroker class is itself relatively cohesive
The PersistentStorageBroker class is a very generic and reusable object
PersistentStorageBroker
save()
By Pure Fabrication

Pure Fabrication
High cohesion is supported because responsibilities are factored into a class that only
focuses on a very specific set of related tasks
Reuse potential may be increased because of the presence of fine grained Pure Fabrication
classes
Preserves low coupling and high cohesion of classes
Improve reusability of classes
Why

Indirection
Assign responsibilities to an intermediate object to mediate between other components
or services, so that they are not directly coupled.
How to assign responsibilities to avoid direct coupling ?
Problem:
To avoid direct coupling?
To de-couple objects so that Low coupling is supported and reuse potential remains high?
Solution:
Assign the responsibility to an intermediate object to mediate between other components or
services, so that they are not directly coupled.

Indirection
Example
PersistentStorageBroker
The Pure fabrication example of de-coupling the Sale from the relational database services through
the introduction of a PersistentStorageBroker is also an example of assigning responsibilities to
support Indirection. The PersistentStorageBroker acts as a intermediary between the Sale and
database

Indirection
Example
Modem
dial( )
receive( )
send( )
By Indirection
Modem::dial(phoneNum)
{
::OS_OpenPort(1);
::OS_Dial(phoneNUM)
}
CreditAuthorizationService Modem1:dial(phoneNum)

Indirection
Low coupling
Promotes reusability
Why

Identify points of predicted variations or instability; assign responsibilities to create a
stable “interface” around them.
How to assign responsibilities to objects, subsystems, and systems so that the variations or
inability in these elements do not have an undesirable impact on other elements ?
Problem:
How to design objects so that variation or instability does not have an undesirable impact on
other elements?
Solution:
Identify points of predicated variation or instability; assign responsibilities to create a stable
interface around them

Core mechanisms for Protected Variations
– Data encapsulation
– Interfaces
– Polymorphism
– Indirection
– Standards (e.g. APIs like JDBC)
• Note that these include virtual machines hiding OS, DB, network, etc

Example
Adaptor
How to resolve incompatible interfaces or provide a stable interface to stable components with
different interfaces?
Convert the original interface of the component into another interface, through an intermediate
adaptor object
It is concept achieved through polymorphism, interfaces and indirection

Example
Among other examples are JDBC and ODBC:
These are packages that allow applications to access databases in a DB-independent way
In spite of the fact that databases all use slightly different methods of communication
It is possible due to an implementation of Protected Variations
Users write code to use a generic interface
An adapter converts the generic method calls to DB-specific communications and vice versa

Why
Protected variations addresses the problem of assigning responsibilities in such a way
that variations that might occur do not have undesirable effects upon other elements
in the system.

Core Design Patterns Classification
Creational Patterns
Have to do with class instantiation
Divided into class creation and object creation
Class creation patterns use inheritance effectively
Object creation patterns use delegation
Structural Patterns
Concern class and object composition
Use inheritance to compose interfaces
Define ways to compose objects to obtain new functionality
Behavioral
Specifically concerned with communication between objects
The Gang of Four (GoF) patterns are generally considered the foundation patterns. There are 23 core design
patterns identified by GoF.

Core Design Patterns Catalog
Purpose
Creational Structural Behavioral
Scope Class Factory Adapter Interpreter
Object Abstract Factory
Singleton
Builder
Prototype
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Template
Visitor
Defer object creation to
another class
Defer object creation to
another object
Describe algorithms and
flow control
Describe ways to
assemble objects
Important patterns

Factory
The Factory pattern provides a way to use an instance as a object factory. The factory can return
an instance of one of several possible classes (in a subclass hierarchy), depending on the data
provided to it.

Factory
Where to use
When a class can't anticipate which kind of class of object it must create
You want to localize the knowledge of which class gets created
When you have classes that is derived from the same subclasses, or they may in fact be
unrelated classes that just share the same interface. Either way, the methods in these class
instances are the same and can be used interchangeably
When you want to insulate the client from the actual type that is being instantiated.

Factory
Example The Connection object in the java package sql is a
factory.
Depending on the database driver you use you
get the database vendors implementation of the
Statement interface.

Factory
Why
The client does not need to know every subclass of objects it must create. It only need one
reference to the abstract class/interface and the factory object.
The factory encapsulate the creation of objects. This can be useful if the creation process is
very complex
Drawbacks/consequences
Gives subclasses a hook for providing an extended version of an object being constructed
There is no way to change an implementing class without a recompile

Abstract Factory
Abstract Factory offers the interface for creating a family of related objects, without explicitly
specifying their classes.
AbstractFactory
Declares an interface for operations that creates
abstract products.
ConcreteFactory
Implements operations to create concrete products.
AbstractProduct
Declares an interface for a type of product objects.
Product
It implements the AbstractProduct interface. Defines
a product to be created by the corresponding
ConcreteFactory.
Client
Uses the interfaces declared by the AbstractFactory
and AbstractProduct classes

Abstract Factory
Where to use
When the system needs to be independent of how its products are created composed and
represented
When the system needs to be configured with one of multiple families of products
When a family of products need to be used together and this constraint needs to be
enforced
When you need to provide a library of products, expose their interfaces not the
implementation

Abstract Factory
Example
We will see code example for better understanding

Abstract Factory
Why
Use of this pattern makes it possible to interchange concrete classes without changing the
code that uses them, even at runtime
Isolates concrete classes
Allows to change product family easily
Promotes consistency among products
As with similar design patterns, one of the main drawbacks is the possibility of unnecessary
complexity and extra work in the initial writing of the code

Singleton
The Singleton pattern provides the possibility to control the number of instances (mostly one)
that are allowed to be made. We also receive a global point of access to it (them).
Structure
Ensure that only one instance of a class is created.
Provide a global point of access to the object.

Singleton
Where to use
When only one instance or a specific number of instances of a class are allowed. Facade
objects are often Singletons because only one Facade object is required
Logger Classes
Configuration Classes
Accessing resources in shared mode

Singleton
Example
class Singleton
{
private static Singleton m_instance;
private Singleton()
{
...
}
public static synchronized Singleton getInstance()
{
if (m_instance == null)
m_instance = new Singleton();
return m_instance;
}
...
public void doSomething()
{
...
}
}
- The getInstance() method ensure that only one
instance of the class is created.
- The only way f instantiating the class to be
through the getInstance() method.
- The getInstance method is used also to provide
a global point of access to the object and it can
be used like this:
Singleton.getInstance().doSomething();

Singleton
Example : Thread-safe implementation for multithreading use
//Lazy instantiation using double locking mechanism.
class Singleton
{
private static Singleton m_instance;
private Singleton()
{
System.out.println("Singleton(): Initializing Instance");
}
public static Singleton getInstance()
{
{
synchronized(Singleton.class)
{
{
System.out.println("getInstance(): First time
getInstance was invoked!");
m_instance = new Singleton();
}
}
}
return m_instance;
}
{
System.out.println("doSomething(): Singleton does something!");
}
}
//Early instantiation using implementation with static field.
class Singleton
{
private static Singleton m_instance = new Singleton();
private Singleton()
{
System.out.println("Singleton(): Initializing Instance");
}
public static Singleton getInstance()
{
return m_instance;
}
{
System.out.println("doSomething(): Singleton does
something!");
}
}

Singleton
Example : Multiple instances
Multiple singleton instances if classes loaded by different classloaders access a singleton.
If a class(same name, same package) is loaded by 2 diferent classloaders they represents 2
different clasess in memory.
Serialization
If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized
and then deserialized more than once, there will be multiple instances of Singleton created.
In order to avoid this the readResolve method should be implemented.
public class Singleton implements Serializable {
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

Singleton
Why
Controlled access to unique instance.
Reduced name space.
Allows refinement of operations and representations.
Singleton pattern is also considered an anti-pattern by some people, who feel that it is overused, introducing unnecessary limitations in situations where a sole instance of a class is not actually required.
The singleton instance is obtained using the class name. At the first view this is an easy way to access it, but it is not very flexible. If we need to replace the Singleton class, all the references in the code should be changed accordingly

Builder
Intention is to abstract steps of construction of objects so that different implementations of
these steps can construct different representations of objects.
Structure
Builder
Abstract interface for creating objects (product).
Concrete Builder
Provide implementation for Builder. Construct and
assemble parts to build the objects.
Director
The Director class is responsible for managing the
correct sequence of object creation. It receives a
Concrete Builder as a parameter and executes the
necessary operations on it.
Product
The final object that will be created by the Director
using Builder.

Builder
Where to use
When the algorithm for creating a complex object should be independent of the parts that
make up the object and how they are assembled
When the construction process must allow different representations for the object that is
constructed
When you want to insulate clients from the knowledge of the actual creation process and/or
resulting product.

Builder
Example
For instance to build a house, we will take several steps:
1. Build floor
2. Build walls
3. Build roof
•Let's use an abstract class HouseBuilder to define these three steps.
•Any subclass of HouseBuilder will follow these three steps to build house
•Then we use a HouseDirector class to force the order of these three steps
•The HouseClient orders the building of two houses
• Wood house
• Brick House
•Even though the houses are of different types (wood and brick) they are built the same
way

Builder
Why
The built object is shielded from the details of its construction.
Code for construction is isolated from code for representation and both are easy to replace
without affecting the other.
Gives you control over the construction process.
Gives you the possibility to reuse and/or change the process and/or product independently.
Need flexibility in creating various complex objects. Need to create complex, aggregate
objects

Adapter
The Adapter pattern is used to translate the interface of one class into another interface.
Structure
Client
Expects a certain interface
Target
Interface expected by client
Adaptee
The available interface
Adapter
Bridges the gap between the Target interface and
the available interface Adaptee.

Adapter
Where to use
When you want to use an existing class, and its interface does not match the one you need
When you want to create a reusable class that cooperates with unrelated or unforeseen
classes, that is, classes that don't necessarily have compatible interfaces
When you want to increase transparency of classes
When you want to make a pluggable kit

Adapter
Example
•FileManagerUtil is the existing utility class that we would like
to adapt to FileManager interface
•We will do the actual adaptation in the class FileManagerImpl
• It uses the desired interface and the existing functionality
through inheritance

Adapter
Why
Highly reusable
Introduces only one object
Target must be an interface

Facade
Provides a unified interface to a set of interfaces in a subsystem.
It defines a higher-level interface that makes the subsystem easier to use.
Structure
Client
The object using the facade to access resources
Facade
Abstracts the internal resources from the rest of the
application

Facade
Where to use
When you want to use an existing class, and its interface does not match the one you need
When you want to create a reusable class that cooperates with unrelated or unforeseen
classes, that is, classes that don't necessarily have compatible interfaces
When you want to increase transparency of classes
When you want to make a pluggable kit

Facade
Example
The Facade class uses the classes
AccountManager, SecurityManager,
AccountReference and BankAccount to
perform the appropriate actions. By using
the Facade pattern we decouple the client
code from the implementation and
security details when performing tasks
related to the bank account.

Facade
Why
Combines very complex method calls and code blocks into a single method that performs a
complex and recurring task
It reduces code dependencies between libraries or packages
Low coupling between the client code and other packages
Reduces network calls
Less control of what goes on beyond the surface
If some classes require small variations to the implementation of Facade methods, we might
end up with a mess

Proxy
A Proxy is a structural pattern that provides a stand-in for another object in order to control
access to it.
Structure
Subject
Interface implemented by the RealSubject and
representing its services.
RealSubject
The real object that the proxy represents
Proxy
Maintains a reference that allows the Proxy to access the
RealSubject
Implements the same interface implemented by the
RealSubject so that the Proxy can be substituted for the
RealSubject
Controls access to the RealSubject and may be
responsible for its creation and deletion

Proxy
Where to use
When the creation of one object is relatively expensive it can be a good idea to replace it
with a proxy that can make sure that instantiation of the expensive object is kept to a
minimum.
Proxy pattern implementation allows for login and authority checking before one reaches
the actual object that's requested
Can provide a local representation for an object in a remote location

Proxy
Example

Proxy
Why
Gives the ability to control access to an object, whether it's because of a costly creation
process of that object or security issues.
Introduces another abstraction level for an object, if some objects accesses the target object
directly and another via the proxy there is a chance that they get different behavior this may
or may not be the intention of the creator

The Chain-of-responsibility pattern lets more than one object handle a request without mutual
knowledge.
Structure
Client
Sends commands to the first object in the chain
that may handle the command
Handler
Defines an interface for handling requests
ConcreteHandler(RequestHandler)
- Handles the requests it is responsible for
- If it can handle the request it does so, otherwise
it sends the request to its successor
Places all handlers in a chain which lets the handler objects pass the request along to the next
handler in the chain until one handles it, or the end of the chain is reached.

Where to use
When more than one object may handle a request, and the handler isn't known
When you want to issue a request to one of several objects without specifying the receiver
explicitly
When the set of objects that can handle a request should be specified dynamically

Example

Why
It reduces coupling
It increases the flexibility of handling a request
Reception isn't guaranteed since a request has no explicit receiver, there's no guarantee it
will be handled unless the chain is configured properly

Command
The Command pattern is used to create objects that represents actions and events in an
application.
Structure
Client
Creates a ConcreteCommand object and sets its receiver
ConcreteCommand
Extends the Command interface, implementing the
Execute method by invoking the corresponding
operations on Receiver. It defines a link between the
Receiver and the action.
Command
Declares an interface for executing an operation
Invoker
Asks the command to carry out the request
Receiver
Knows how to perform the operations
- encapsulate a request in an object
- allows the parameterization of clients with different requests
- allows saving the requests in a queue

Command
Where to use
Where you want a action that can be represented in many ways, like dropdown menu,
buttons and popup menu
To create undo/redo functionality

Command
Example

Command
Why
A command object is a possible storage for procedure parameters. It can be used while
assembling the parameters for a function call and allows the command to be set aside for
later use
A class is a suitable place to collect code and data related to a specific action or event
It allows the reaction to a command to be executed some time after it has occurred
Command objects enables data structures containing multiple commands
Command objects supports undo-able operations, provided that the command objects are
stored (for example in a linked list).
There are implementations of this design pattern in which the invoker is aware of the
concrete commands classes
This is wrong making the implementation more tightly coupled. The invoker should be aware
only about the abstract command class.

Mediator
Define an object that encapsulates how a set of objects interact.
Structure
Mediator
Defines an interface for communicating colleague objects.
ConcreteMediator
Knows the colleague classes and keep a reference to the
colleague classes.
- Implements the communication and transfer the
message between the colleague classes
Colleague classes
Keep a reference to its Mediator object
- Communicates with the Mediator whenever it would
have otherwise communicated with another Colleague
With the mediator pattern communication between objects is encapsulated with a mediator
object. Objects no longer communicate directly with each other, but instead communicate
through the mediator.

Mediator
Where to use
The Mediator pattern can be used when a set of objects communicate in well-specified but
complex ways and the resulting interdependencies are unstructured and hard to grasp
If it is difficult to reuse an object because it refers to and communicates with many other
objects this pattern is a good solution
A behavior that is distributed between several classes should be customizable without a lot
of subclassing

Mediator
Example

Mediator
Why
Limited subclassing, since a mediator localizes behavior that otherwise would be distributed
among several objects. Changing some behavior requires us to subclass only the mediator.
Colleagues become decoupled which allows us to vary and reuse colleague and mediator
classes independently
A mediator simplifies object protocols since it replaces many-to-many interactions with one-
to-many interactions between the mediator and its colleagues. One-to-many interactions
are easier to understand, maintain, and extend
The mediator abstracts object cooperation. The mediator lets you focus on how objects
interact apart from their individual behaviors which can help clarify how objects interact in a
system
The Mediator pattern can have a performance impact on a system. Since all communication
must go through the mediator, it can become a bottleneck
In practice mediators tends to become more complex and complex. A good practice is to
take care to make the mediator classes responsible only for the communication part

Observer
Define a one-to-many dependency between objects so that when one object changes state, all its
dependents are notified and updated automatically.
Structure
Subject
Interface or abstract class defining the operations for
attaching and detaching observers to the client.
Observer (IObserver)
Interface or abstract class defining the operations to be
used to notify this object.
Observer class
It maintains the state of the object and when change in
the state occurs it notifies the attached observers
Pattern that enables publish/subscribe functionality. This is accomplished by an autonomous
object, publisher that allows other objects to attach or detach their subscription as they like.
The pattern does not impose any limit to the number of observers that can attach, or
subscribe, themselves for notification on future changes in the publisher's state.

Observer
Where to use
When an object wants to publish information and many objects will need to receive that
information
The change of a state in one object must be reflected in another object without keeping the
objects tightly coupled
The framework needs to be enhanced in future with new observers with minimal changes

Observer
Example

Observer
Why
Makes for a loose coupling between publisher and subscriber as the publisher does not need
to know who or how many subscribers there will be
In a complex scenario there may be problems to determining whether the update to the
publisher is of relevance to all subscribers or just some of them. Sending an update signal to
all subscribers might impose a communication overhead of not needed information

Reference
Design Principles and Design Patterns – Robert C. Martin
www.objectmentor.com
Applying UML and Patterns 3rd
Edition – Craig Larman
http://www.oodesign.com/
The Gang of Four (GoF) Patterns

DesignPrinciples-and-DesignPatterns

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie DesignPrinciples-and-DesignPatterns

Ähnlich wie DesignPrinciples-and-DesignPatterns (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

DesignPrinciples-and-DesignPatterns

Hinweis der Redaktion