Unit IV
GOF Design
Patterns
Introduction
Object Oriented Analysis (OOA)
domain problem designed as (domain) objects
addresses the functional challenges
what a system does
provides guidance for implementation
Object Oriented Design (OOD)
domain problem solved as (implementation)
objects
addresses the implementation challenges
how a system realizes OOA
Introduction
How can we improve OOD:
identify common characteristics
creation, structure, behaviour & interactions
design patterns (design reuse)
generic blueprints (micro architecture)
language and implementation independent
Two main catalogues
GoF: Gang of Four (Gamma, Helm, Johnson, Vlissides,
1995)
POSA: Pattern Oriented Software Architecture
Introduction
What is a Design Pattern?
"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 ever doing it the same way twice
A Pattern has four elements namely:
A Pattern name
Problem
Solution
Consequences
Design Pattern Classification
Design Pattern Classification
Purpose based classification
creational: concerns with creation process of objects &
classes
structural: composition of classes & objects
behavioral: characterizes interaction & responsibility of
objects & classes
Scope based classification : decided if the pattern
applies to mainly classes or objects
Two categories
class scope
relationship between classes & subclasses
statically defined at run-time
object scope
object relationships (what type?)
Design Pattern Classification
GOF Patterns
Creational Design Patterns
Structural Design Patterns
Behavioral Design Patterns
Applying Design Patterns
Creational Design Patterns
Creational design patterns are design patterns that deal with object creation
mechanisms, trying to create objects in a manner suitable to the situation.
Creational design patterns abstract the instantiation process.
There are two
recurring themes in these patterns.
First, they all encapsulate knowledge about which concrete classes the system
uses.
Second, they hide how instances of these classes are created and put together.
Types:
Factory Method
Abstract Factory
Builder
Prototype
Singleton
Abstract Factory
1) Implement a user interface toolkit that supports multiple
looks and feel standards such as Motif, Windows 95 or the
finder in MacOS.
How can you write a single user interface and make it
portable across the different look and feel standards for these
window managers?
2) Implement a facility management system for an intelligent
house
that
supports
different
control
systems
such
as
Siemens Instabus, Johnson & Control Metasys or Zumtobes
proprietary standard.
How
can
you
write
single
control
independent from the manufacturer?
system
that
is
Abstract Factory
Abstract Factory - Example
We have a class named SomeApp that depends on the interface Shape.
Shape uses object of Shape only through the Shape interface.
Problem: SomeApp also creates instances of Square and Circle and thus
has to depend on the concrete classes.
SomeApp
<<Interface>>
Shape
Square
<<creates>>
Circle
Abstract Factory - Example
Solution: ShapeFactory interface.
SomeApp
<<Interface>>
Shape
<<Interface>>
ShapeFactory
makeSquare()
makeCircle()
ShapeFactory
Implementation
Square
<<creates>>
Circle
Abstract Factory - Example
Intent:
Provide an interface for creating families of related or
dependent objects without specifying their concrete
classes.
Applicability - Use the Abstract Factory pattern
when
1) Independence from Initialization or Representation:
The system should be independent of how its products are created,
composed or represented
2) Manufacturer Independence:
A system should be configured with one of multiple family of
products
You want to provide a class library for a customer (facility
management library), but you dont want to reveal what
particular product you are using.
3) Constraints on related products
A family of related products is designed to be used together and
you need to enforce this constraint
4) Cope with upcoming change:
Abstract Factory - Example
Factory Method - example
For example, a framework for a windowing application has a
class Application which must create an object of class
Document
But the actual applications and documents are not written
yet!
Solution:
Let subclasses decide which objects to represent
Application
subclasses
redefine
an
abstract
CreateDocument operation on Application to return the
appropriate Document subclass.
Once an Application subclass is instantiated, it can then
instantiate application-specific Documents without knowing
their class.
We call CreateDocument a factory method because it's
responsible for "manufacturing" an object.
Factory Method - example
Separate creation into a method
the factory method in the MyApplication class:
public Document CreateDocument() { return new
MyDocument();}
client code:
public Application app1;
app1 = new MyApplication();
app1.CreateDocument();
Factory Method
Intent:
Define an interface for creating an object, but let subclasses decide which class to
instantiate.
Factory Method lets a class defer instantiation to subclasses.
Structure
Singleton
Intent - ensure a class only has one
instance, and provide a global point of access
to it.
Advantages
controlled access to the class instance(s)
can dictate who, and when a client can
access
refinement of functionality
via inheritance/subclass
Singleton
singleton class responsible for creation
acts as a builder/factory
what if we were to separate the two concerns
example
database connection as a singleton
system 1 uses a singleton to ensure only a
single database connection
system 2 needs to pool of 10 databases
connections
Adapter
convert the interface of a class into another
interface... Adapter lets classes work together
that couldn't otherwise because of incompatible
interface
also known as wrapper
boolean values can be represented by
{1,0}, {true, false}, {yes, no}
Adapter Pattern
1) Convert the interface of a class into another interface
expected by the client. Adapter lets classes work together
that couldnt otherwise because of incompatible interfaces
2) Used to provide a new interface to existing legacy
components (Interface engineering, reengineering).
3) Also known as a wrapper
4) Two adapter patterns:
Class adapter:
- Uses multiple inheritance to adapt one interface to
another
Object adapter:
- Uses single inheritance and delegation
5) We will mostly use object adapters and call them simply
adapters
Adapter
Intent:
Convert the interface of a class into another interface clients expect. Adapter lets
classes work together that couldn't otherwise because of incompatible interfaces.
Structure
Class Adapter Pattern
Class Adapter Pattern (based on Multiple Inheritance)
Adapter pattern uses delegation and inheritance
Adapter pattern uses delegation and inheritance
Delegation is used to bind an Adapter and an Adaptee
1) Interface inheritance is use to specify the interface of
the Adapter class.
2) Adaptee, usually called legacy system, pre-exists the
Adapter.
3) Target may be realized as an interface in Java.
Bridge Pattern
Decouple an abstraction from its implementation so that the two can
vary independently.
Bridge makes a clear-cut between abstraction and implementation.
Where to use
When you want to separate the abstract structure and its concrete
implementation.
When you want to share an implementation among multiple objects,
When you want to reuse existing resources in an 'easy to extend'
fashion.
When you want to hide implementation details from clients. Changes in
implementation should have no impact on clients.
Benefits
Implementation can be selected or switched at run-time. The
abstraction and implementation can be independently extended or
composed.
example
Bridge pattern can be found in the AWT
package. The AWT separates the general
abstraction of GUI components from concrete
native implementations of
Car GUI components.
Ford
SportyFord
Toyota
ToyotaTruck
Sporty
FordTruck
Truck
SportyToyota
Composite Pattern
The Composite pattern helps you to create tree structures of objects
without the need to force clients to differentiate between branches
and leaves regarding usage. The Composite pattern lets clients treat
individual objects and compositions of objects uniformly.
Where to use
When you want to represent a part-whole relationship in a tree
structure.
When you want clients to be able to ignore the differences between
compositions of objects and individual objects.
When the structure can have any level of complexity and is dynamic.
Benefits
Define class hierarchies consisting of primitive objects and composite
objects.
Makes it easier to add new kind of components.
Design Patterns - Facade Pattern
Facade Pattern
1) Provides a unified interface to a set of objects in a
subsystem. A facade defines a higher-level interface that
makes the subsystem easier to use (i.e. it abstracts out
the gory details)
2) Facades allow us to provide a closed architecture
Design Patterns - Open vs Closed Architecture
Open vs Closed Architecture
1) Open architecture:
w Any dealer management system
can call any component or class
operation of the PAID databases.
2) Why is this good?
w Efficiency
3) Why is this bad?
Cant expect the client to
understand how the subsystem
works or any of the complex
relationships that may exist
within the subsystem.
We can (pretty much) be assured
that the subsystem will be
misused, leading to non-portable
Decorator Pattern
Widget Example
Suppose you have a user interface toolkit and you wish to
make a border or scrolling feature available to clients without
defining new subclasses of all existing classes.
The client "attaches" the border or scrolling responsibility to
only those objects requiring these capabilities.
Widget* aWidget = new BorderDecorator(
new ScrollDecorator(new TextView), 1);
aWidget->draw();
Stream Example
cascading responsibilities on to an output stream
Stream* aStream = new CompressingStream(
new ASCII7Stream(
new FileStream( "fileName.dat" )));
aStream->putString( "Hello world" );
Decorator Pattern
VisualComponent
draw()
TextView
draw()
ScrollDecorator
scrollPosition
draw()
scrollto()
Decorator
draw()
+component
component.draw()
BorderDecorator
borderWidth
draw()
drawBorder()
super.draw()
drawBorder()
Decorator subclasses are free to add operations for specific functionality.
For example, ScrollDecorator's ScrollTo operation lets other objects scroll the
interface if they know there happens to be a ScrollDecorator object in the
interface.
Decorator Pattern
Painting Example
Although paintings can be hung on a wall with or without
frames, frames are often added, and it is the frame which is
actually hung on the wall.
Prior to hanging, the paintings may be matted and framed,
with the painting, matting, and frame forming a single visual
Decorator Pattern - Structure
Intent
Attach additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for extending
functionality.
Structure
Structure
Decorator Pattern Example(TestEoF.java)
InputStream
(from i o)
read() : int
-in
FileInputStream
FilterInputStream
(from i o)
(from i o)
FileInputStream(arg0 : String)
read() : int
FilterInputStream(arg0 : InputStream)
read() : int
BufferedInputStream
DataInputStream
(from i o)
(from io)
BufferedInputStream(arg0 : InputStream)
read() : int
DataInputStream(arg0 : InputStream)
readByte() : byte
Proxy Pattern
What is expensive?
Object Creation
Object Initialization
Defer creation and initialization to the
time you need the object
Reduce the cost of access to objects
Use another object (the proxy) that acts as a
stand-in for the real object
The proxy creates the real object only if the user
asks for it
Proxy Pattern - Motivation
Example
The Proxy provides a surrogate or place holder to provide
access to an object.
A check or bank draft is a proxy for funds in an account.
A check can be used in place of cash for making purchases
and ultimately controls access to cash in the issuer's account.
Proxy Pattern - Structure
Intent
Provide a surrogate or placeholder for another object to control access to it.
Problem
You need to support resource-hungry objects, and you do not want to
instantiate such objects unless and until they are actually requested by the
client.
Structure
Behaviour Design Pattern
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.
Behavioral patterns are patterns that focuses on the
interactions between cooperating objects.
The interactions between cooperating objects should be
such that they are communicating while maintaining as
loose coupling as possible.
Observer pattern
Also known as: Publish / Subscribe, Model / View, and
Source / Listener.
Motivation: Two File Managers are both observing the
same Directory; the user
deletes a subdirectory using File Manager A; we want File
Manager B to
immediately and automatically get updated, reflecting the
change...
Applicability:
When there are multiple views of a model (subject) that
need to stay in sync.
No view should know about any other.
When an object needs to communicate to other objects
of unknown type (but known Observer interface) it can
notify them.
Pros:
Promotes loose coupling between objects.
Observer pattern
Intent: Define a one-to-many dependency
between objects so that when one object
changes state, all its dependents are
notified and updated automatically.
Observer pattern Example
Java Support for Observer
l The java.util package provides an Observable class and an Observer interface:
Example: A GUI Observes a
Person
Example: A GUI Observes a
Person
Example: Event-driven
programming
In the case of a JButton, this event of interest is that the
button is pressed. To register your interest in when a button
is pressed, you call the JButtons addActionListener()
method. This method expects an argument that is an object
that implements the ActionListener interface, which contains
a single method called actionPerformed(). So all you have to
do to attach code to a JButton is to implement the
ActionListener interface in a class, and register an object of
that class with the JButton via<<Interface>>
addActionListener().
The
Event
method will be calledEvent
when the EventListener
button
is pressed (this is
handler
(from util)
Button2
EventObject
JButton
normally
referred
to
as
a
callback).
(from util)
Sources
init() : void
(from swing)
getSource() : Object
<<Interface>>
ActionListener
AbstractButton
(from swing)
(from event)
addActionListener(arg0 : ActionListener) : void
Register event handler to
event source
AWTEvent
actionPerformed(arg0 : ActionEvent) : void
(from awt)
Events
BL
(from Button2)
actionPerformed(arg0 : ActionEvent) : void
ActionEvent
(from event)
Strategy Pattern
Many algorithms exist for breaking a stream of text into lines. Hard-wiring
all such algorithms into the classes that require them isn't desirable for
several reasons:
Clients that need linebreaking get more complex if they include the linebreaking code. That makes
clients bigger and harder to maintain, especially if they support multiple linebreaking algorithms.
Different algorithms will be appropriate at different times. We don't want to support multiple
linebreaking algorithms if we don't use them all.
It's difficult to add new algorithms and vary existing ones when linebreaking is an integral part of
a client.
We can avoid these problems by defining classes that encapsulate
different linebreaking algorithms.
An algorithm that's encapsulated in this way is called a strategy.
Strategy Pattern
Intent
Define a family of algorithms, encapsulate each one, and make
them interchangeable. Strategy lets the algorithm vary
independently from the clients that use it.
Structure
Strategy Pattern
A Strategy defines a set of algorithms that can be
used interchangeably.
Modes of transportation to an airport is an example of
a Strategy.
Several options exist such as driving one's own car, taking a taxi, an
airport shuttle, a city bus, or a limousine service.
For some airports, subways and helicopters are also available as a
mode of transportation to the airport.
Any of these modes of transportation will get a traveler to the airport,
and they can be used interchangeably.
The traveler must chose the Strategy based on tradeoffs between cost,
convenience, and time.
Strategy Pattern Example
In this inflexible example, all the NumberCruncher code is in one big
class Why is this bad?
Strategy is similar to Bridge; same basic structure; very different intent.
The Strategy pattern is also similar to State, which allows a class to be
configured with different behaviors from which it can select whenever it
makes an interesting state transition.
Strategy Pattern
What if there were not a CrunchAlgorithm interface suppose instead that
NumberCruncher had two subclasses, CorrectButSlowNumberCruncher, and
FastButSloppyNumberCruncher? Why is this bad?
Iterator Pattern
An aggregate object such as a list should give you a way to access its
elements without exposing its internal structure.
The key idea is to take the responsibility for access and traversal
out of the list object and put it into an iterator object.
Iterator Pattern
Intent
Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation.
Structure
