0% found this document useful (0 votes)
13 views

5. Creational Design Patterns

The document discusses various creational design patterns in software development, including Factory Method, Abstract Factory, Builder, and Singleton. Each pattern is explained with its intent, problems it solves, solutions, and examples. The document emphasizes the benefits of using these patterns to improve code robustness, reduce coupling, and enhance extensibility.
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views

5. Creational Design Patterns

The document discusses various creational design patterns in software development, including Factory Method, Abstract Factory, Builder, and Singleton. Each pattern is explained with its intent, problems it solves, solutions, and examples. The document emphasizes the benefits of using these patterns to improve code robustness, reduce coupling, and enhance extensibility.
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 44

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://refactoring.guru/design-patterns
https://javatechonline.com/java-design-patterns-java/
https://www.tutorialspoint.com/design_pattern/
https://www.javatpoint.com/design-patterns-in-java

3
4
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.

5
Solution

6
Example: Drawing

<<interface>> Client
Shape
+ draw()

Circle Square Rectangle ShapeFactory


+drawShape(type):Shape
+ draw() + draw() + draw()

7
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

8
Example: Kiosk

<<interface>> Kiosk
PaymentProcessor
+ processPayment()

GetPayment
Cash CreditCard Coupon +getProcessor(type):
PaymentProcessor
+ prcessPayment() + prcessPayment() + prcessPayment()

9
Factory

10
11
12
Another Example Usecase

• Imagine that you’re creating a logistics management application. The


first version of your app can only handle transportation by trucks, so
the bulk of your code lives inside the Truck class.
• After a while, your app becomes pretty popular. Each day you receive
dozens of requests from sea transportation companies to incorporate
sea logistics into the app.
• Great news, right? But how about the code? At present, most of your
code is coupled to the Truck class. Adding Ships into the app would
require making changes to the entire codebase. Moreover, if later
you decide to add another type of transportation to the app, you will
probably need to make all of these changes again.
• As a result, you will end up with pretty nasty code, riddled with
conditionals that switch the app’s behavior depending on the class of
transportation objects.
• Solution: https://refactoring.guru/design-patterns/factory-method

13
Another Example

https://refactoring.guru/design-patterns/factory-method
14
Use the Factory Method when you want to
provide users of your library or framework
with a way to extend its internal
components
• Imagine that you write an app using an open source UI
framework.
• Your app should have round buttons, but the framework only
provides square ones.
• You extend the standard Button class with a
glorious RoundButton subclass.
• But now you need to tell the main UIFramework class to use the
new button subclass instead of a default one.
• To achieve this, you create a subclass UIWithRoundButtons from a
base framework class and override its createButton method.
• While this method returns Button objects in the base class, you
make your subclass return RoundButton objects.
• Now use the UIWithRoundButtons class instead of UIFramework.
15
Consequences/Benefits
• 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.

16
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

17
Solution

18
Example: Car Factory
<<interface>> Client
HondaFactory
+ createEngine()
+ createTrans()

Engine

CivicFactory AccordFactory
+ createEngine() + createEngine()
+ createTrans() + createTrans()
CivicEngine AccordEngine

Transmission

CivicTrans AccordTrans

19
https://www.tutorialspoint.com/design_pattern/
design_pattern_quick_guide.htm

20
21
22
Abstract Factory

23
24
25
26
27
28
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

29
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.

30
Solution

SingletonClass
- instance: SingletonClass

- SingletonClass()
+ getInstance(): SingletonClass

31
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();
32
Consequences
• Controlled access to sole instance

• Reduced namespace

• Permits variable number of instances

33
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.

34
Solution

35
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).

36
Consequences
• Lets you vary a product’s internal representation

• Isolates construction and representation

• Gives you finer control over the construction process

37
38
39
40
Builder

41
42
43
44

You might also like