Creational Patterns
1
UML Revisited
Aggregation: “is part of”
Composition: “is entirely made of”
Generalization
Dependency: “uses”
2
Creational Patterns to be Covered
ꟷFactory method
ꟷAbstract factory
ꟷBuilder
ꟷSingleton
Examples taken from:
https://www.tutorialspoint.com/design_pattern/
https://www.javatpoint.com/design-patterns-in-java
3
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.
Problem • A framework needs to standardize the
architectural model for a range of applications,
but allow for individual applications to define
their own domain objects and provide for their
instantiation.
• Enable the creator to defer product creation to
sub-class.
4
Solution
5
Example: Drawing
<<interface>> Client
Shape
+ draw()
Circle Square Rectangle ShapeFactory
+drawShape(type):Shape
+ draw() + draw() + draw()
6
public interface Shape {
void draw();
}
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Inside Rectangle::draw() method.");
}
}
Similar implementation for Square and Circle
7
Example: Kiosk
<<interface>> Kiosk
PaymentProcessor
+ processPayment()
GetPayment
Cash CreditCard Coupon +getProcessor(type):
PaymentProcessor
+ prcessPayment() + prcessPayment() + prcessPayment()
8
Factory
9
10
11
Consequences
• Factory design pattern provides approach to code for interface rather
than implementation.
• Factory pattern removes the instantiation of actual implementation
classes from client code. Factory pattern makes our code more
robust, less coupled and easy to extend. For example, we can easily
change lower class implementation because client program is
unaware of this.
• Factory pattern provides abstraction between implementation and
client classes through inheritance.
12
Abstract Factory
Intent • Provide an interface for creating families of
related or dependent objects without
specifying their concrete classes.
Problem • A portable application needs to encapsulate
platform dependencies
• Consider an application that support multiple
look and feels.
• An application need to work with multiple
types of DBMS
13
Solution
14
Example: Car Factory
<<interface>> Client
HondaFactory
+ createEngine()
+ createTrans()
Engine
CivicFactory AccordFactory
+ createEngine() + createEngine()
+ createTrans() + createTrans()
CivicEngine AccordEngine
Transmission
CivicTrans AccordTrans
15
https://www.tutorialspoint.com/design_pattern/design_pattern
_quick_guide.htm
16
17
18
Abstract Factory
19
20
21
22
23
24
Consequences
• Isolates the concrete class
• Makes exchanging product family easy
• Promotes consistency among products
• Abstract Factory design pattern provides approach to code for
interface rather than implementation.
• Abstract Factory pattern is “factory of factories” and can be easily
extended to accommodate more products.
• Abstract Factory pattern is robust and avoid conditional logic of
Factory pattern.
• Supporting new types of products is difficult
25
Singleton
Intent • Ensure a class has only one instance, and
provide a global point of access to it.
• Encapsulated "just-in-time initialization" or
"initialization on first use".
Problem • Application needs one, and only one, instance
of an object. Additionally, lazy initialization and
global access are necessary.
26
Solution
SingletonClass
- instance: SingletonClass
- SingletonClass()
+ getInstance(): SingletonClass
27
Example: DB Connection Manger
public class DbConnection{
private static DbConnection instance=null;
private SQLConnection connection;
private DbConnection() {
connection = connectToDatabase(dbUser,dbPassword,dbName);
}
public static getDbConnection() {
if (instance== null )
instance = new DbConnection() ;
return instance;
}
}
DbConnection connection=DbConnection.getDbConnection();
28
Consequences
• Controlled access to sole instance
• Reduced namespace
• Permits variable number of instances
29
Builder
Intent • Separate the construction of a complex object
from its representation so that the same
construction process can create different
representations.
• Parse a complex representation, create one of
several targets.
Problem • An application needs to create the elements of
a complex aggregate. The specification for the
aggregate exists on secondary storage and one
of many representations needs to be built in
primary storage.
30
Solution
31
Examples
To create a computer,
different parts are assembled
depending upon the order
received by the customer
(e.g., a customer can demand
a 500 GB hard disk with an
Intel processor; another
customer can choose a 250
GB hard disk with an AMD
processor).
32
Consequences
• Lets you vary a product’s internal representation
• Isolates construction and representation
• Gives you finer control over the construction process
33
34
35
36
Builder
37
38
39
40
Structural Patterns
1
Motivation: Adapter
2
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.
• Wrap an existing class with a new interface.
Problem • An "off the shelf" component offers compelling
functionality that you would like to reuse, but
its "view of the world" is not compatible with
the philosophy and architecture of the system
currently being developed.
3
Solution
4
Example: Car Factory
Client
<<interface>>
PowerAdapter
+connectPower()
EuroInterface USInterface USSocket
+connectPower() +connectPower() +powerConnection()
5
6
7
8
Adapter
9
10
11
Consequences
• Allows pre-existing classes to be used in your code.
• Will not work if existing class is missing some key behavior.
12
Motivation: Decorator
13
Decorator
Intent • Attach additional responsibilities to an object
dynamically. Decorators provide a flexible
alternative to subclassing for extending
functionality.
• Client-specified embellishment of a core object
by recursively wrapping it.
• Wrapping a gift, putting it in a box, and
wrapping the box.
Problem • You want to add behavior or state to individual
objects at run-time. Inheritance is not feasible
because it is static and applies to an entire
class.
14
Solution
15
16
17
18
Decorator
19
20
21
22
23
Consequences
• More flexibility than static inheritance
• Pay-as-you-go approach
• Lots of little objects
24
Composite
Intent • Compose objects into tree structures to
represent whole-part hierarchies. Composite
lets clients treat individual objects and
compositions of objects uniformly.
• Recursive composition
Problem • Application needs to manipulate a hierarchical
collection of "primitive" and "composite"
objects. Processing of a primitive object is
handled one way, and processing of a
composite object is handled differently. Having
to query the "type" of each object before
attempting to process it is not desirable.
25
Components
Composite Pattern consists of following
objects:
• Base Component – Base component is
the interface for all objects in the
composition, client program uses base
component to work with the objects in
the composition. It can be an interface or
an abstract class with some methods
common to all the objects.
• Leaf – Defines the behaviour for the
elements in the composition. It is the
building block for the composition and
implements base component. It doesn’t
have references to other Components.
• Composite – It consists of leaf elements
and implements the operations in base
component.
26
Example
27
28
29
30
31
32
33
34
35
36
Consequences
• Makes the client simple
• Easier to add new kinds of components
37
State
Intent • Allow an object to alter its behavior when its
internal state changes. The object will appear
to change its class.
Problem • A monolithic object's behavior is a function of
its state, and it must change its behavior at run-
time depending on that state.
1
Solution
2
Example
3
4
5
6
7
Consequences
• Localizes the state specific behavior
• Makes state transitions explicit
8
Motivation: Strategy
• Quick sort
• Merge sort
• Insertion sort
• Bubble sort
• Radix sort
• Heap sort
• Bucket sort
• ..
9
Strategy
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.
Problem • Capture the abstraction in an interface, bury
implementation details in derived classes.
10
Solution
11
12
13
14
15
16
17
Consequences
• Families of related algorithms
• Eliminate conditional statements
• Client must be aware of different strategies
18
Motivation: Observer
19
Observer
Intent • Define a one-to-many dependency between
objects so that when one object changes state,
all its dependents are notified and updated
automatically.
Problem • Encapsulate the core (or common or engine)
components in a Subject abstraction, and the
variable (or optional or user interface)
components in an Observer hierarchy.
20
Solution
21
22
23
Consequences
• Decoupling subject and observer
• Support broadcast communication
24
Many observers, many subjects
25
26
27
28
Mediator
29
30
31
32
33
34
35
36
37
38
Template
Intent • Template Method is a behavioral design
pattern that defines the skeleton of an
algorithm in the superclass but lets subclasses
override specific steps of the algorithm without
changing its structure.
Solution • The Template Method lets you turn a
monolithic algorithm into a series of individual
steps which can be easily extended by
subclasses while keeping intact the structure
defined in a superclass.
39
40
41
42
43
44
45
Command
Intent • Command is a behavioral design pattern that
turns a request into a stand-alone object that
contains all information about the request. This
transformation lets you parameterize methods
with different requests, delay or queue a
request’s execution, and support undoable
operations.
Solution • The Command pattern can turn a specific
method call into a stand-alone object. This
change opens up a lot of interesting uses: you
can pass commands as method arguments,
store them inside other objects, switch linked
commands at runtime, etc
46
47
48
49
50
51
52
53
