Creational Patterns

Abstract Factory, Factory Method

Making Objects
The Smart Way
Pranamya Jain 151070047
Siddhesh Gangan 151090052
Yash Jain 151070057
Siddhesh Rane 161070981
 What are creational patterns?
• Design patterns that deal with object creation
mechanisms, trying to create objects in a manner
suitable to the situation
• Make a system independent of the way in which
objects are created, composed and represented
• Recurring themes:
– Encapsulate knowledge about which concrete classes the
system uses (so we can change them easily later)
– Hide how instances of these classes are created and put
together (so we can change it easily later)
 Benefits of creational patterns
• Creational patterns let you program to an
interface defined by an abstract class
• That lets you configure a system with
“product” objects that vary widely in
structure and functionality
• Example: GUI systems
– InterViews GUI class library
– Multiple look-and-feels
– Abstract Factories for different screen
components
 Benefits of creational patterns
• Generic instantiation – Objects are instantiated
without having to identify a specific class type in
client code (Abstract Factory, Factory)
• Simplicity – Make instantiation easier: callers do not
have to write long complex code to instantiate and
set up an object (Builder, Prototype pattern)
• Creation constraints – Creational patterns can put
bounds on who can create objects, how they are
created, and when they are created
 Abstract Factory: Overview

• Intent
– Provide an interface for creating families of related or
dependent objects without specifying their concrete
classes
• Analogous to a pasta maker
Your code is the pasta maker
Different disks create different pasta shapes:
these are the factories
All disks have certain properties in common
so that they will work with the pasta maker
All pastas have certain characteristics in
common that are inherited from the generic
“Pasta” object
Abstract Factory: Motivation

A Modern-style sofa doesn’t match Victorian-style chairs.

 Abstract Factory: Motivation

The client shouldn’t care about the concrete class of the factory it works with.
 Abstract Factory: Participants
• Abstract Products
Declare interfaces for a set of distinct but related products which make up a product family.

• Concrete Products
Are various implementations of abstract products, grouped by variants. Each abstract
product (chair/sofa) must be implemented in all given variants (Victorian/Modern).

• Abstract Factory
Declares a set of methods for creating each of the abstract products.

• Concrete Factories
Implement creation methods of the abstract factory. Each concrete factory corresponds to a
specific variant of products and creates only those product variants.

• Client
The Client can work with any concrete factory/product variant, as long as it communicates
with their objects via abstract interfaces.
Abstract Factory: Participants
 Abstract Factory: Collaborations
• Usually only one ConcreteFactory instance is used for an
activation, matched to a specific application context. It builds
a specific product family for client use -- the client doesn’t
care which family is used -- it simply needs the services
appropriate for the current context.

• The client may use the AbstractFactory interface to initiate

creation, or some other agent may use the AbstractFactory
on the client’s behalf.

• The factory returns, to its clients, specific product instances

bound to the product interface. This is what clients use for
all access to the instances.
 Abstract Factory: Applicability
• Use Abstract Factory when:

– Use the Abstract Factory when your code needs

to work with various families of related products,
but you don’t want it to depend on the concrete
classes of those products—they might be
unknown beforehand or you simply want to allow
for future extensibility.
Abstract Factory: Implementation
1. Map out a matrix of distinct product types versus variants of these
products.
2. Declare abstract product interfaces for all product types. Then make
all concrete product classes implement these interfaces.
3. Declare the abstract factory interface with a set of creation methods
for all abstract products.
4. Implement a set of concrete factory classes, one for each product
variant.
5. Create factory initialization code somewhere in the app. It should
instantiate one of the concrete factory classes, depending on the
application configuration or the current environment. Pass this factory
object to all classes that construct products.
6. Scan through the code and find all direct calls to product constructors.
Replace them with calls to the appropriate creation method on the
factory object.
 Case Study
Using Abstract Factory pattern for creating cross-
platform UI elements without coupling the client code to
concrete UI classes, while keeping all created elements
consistent with a selected operating system.

Problem:
● The same UI elements in a cross-platform application
are expected to behave similarly, but look a little bit
different under different operating systems. Moreover,
to make sure that the UI elements match the style of the
current operating system. You wouldn’t want your
program to render macOS controls when it’s executed
in Windows.
Solution:
➔ The Abstract Factory interface declares a set of creation methods
that the client code can use to produce different types of UI
elements. Concrete factories correspond to specific operating
systems and create the UI elements that match that particular OS.

➔ When an application launches, it checks the type of the current

operating system. The app uses this information to create a
factory object from a class that matches the operating system.
The rest of the code uses this factory to create UI elements. This
prevents the wrong elements from being created.

➔ The client code doesn’t depend on concrete classes of factories

and UI elements as long as it works with these objects via their
abstract interfaces. This also lets the client code support other
factories or UI elements that you might add in the future.

➔ No need to modify the client code each time you add a new
variation of UI elements to your app. Just have to create a new
factory class that produces these elements and slightly modify the
app’s initialization code so it selects that class when appropriate.
 Abstract Factory: Consequences
• Pros:
– Isolates concrete classes
• All manipulation on client-side done through abstract interfaces
– Makes exchanging product families easy
• Just change the ConcreteFactory
– Enforces consistency & compatibility among products
• Cons:
– The code may become more complicated than it should
be.
– Lot of new interfaces and classes are introduced along
with the pattern.
Abstract Factory: Related Patterns
1. Abstract Factory specializes in creating families of related objects. Abstract
Factory returns the product immediately, whereas Builder lets you run
some additional construction steps before fetching the product.
2. Abstract Factory classes are often based on a set of Factory Methods, but
you can also use Prototype to compose the methods on these classes.
3. Abstract Factory can serve as an alternative to Facade when you only
want to hide the way the subsystem objects are created from the client
code.
4. You can use Abstract Factory along with Bridge. This pairing is useful
when some abstractions defined by Bridge can only work with specific
implementations. In this case, Abstract Factory can encapsulate these
relations and hide the complexity from the client code.
5. Abstract Factories, Builders and Prototypes can all be implemented as
Singletons.
 Factory Method: Overview
• 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.
 Factory Method: Motivation

➔ Creating a logistics management application.

➔ The first version of your app can only handle transportation by
trucks.
➔ Requests from sea transportation companies to incorporate sea
logistics into the app.
➔ Replace direct object construction calls (using the new operator) with
calls to a special factory method.
➔ Objects returned by a factory method are often referred to as “products.”
➔ Can override the factory method in a subclass and change the class of
products being created by the method.
➔ Both Truck and Ship classes should implement the Transport
interface, which declares a method called deliver.
➔ Each class implements this method differently: trucks deliver cargo
by land, ships deliver cargo by sea.
➔ The factory method in the RoadLogistics class returns truck
objects, whereas the factory method in the SeaLogistics class
returns ships.
 Factory Method: Participants
• Product
The Product declares the interface, which is common to all objects that can be
produced by the creator and its subclasses.

• Concrete Products
Concrete Products are different implementations of the product interface.

• Creator
The Creator class declares the factory method that returns new product objects.
It’s important that the return type of this method matches the product interface.

• Concrete Creators
Concrete Creators override the base factory method so it returns a different type
of product.
 Factory Method: Collaborations

• The Creator relies on the subclass’s factory method

to return an instance of appropriate
ConcreteProduct object.

• The Creator executes some sequence of operations

on the object or simply returns a reference to
Product (bound to the ConcreteProduct object) to
the client.
 Factory Method: Applicability
• Use Factory Method when:

1. You don’t know beforehand the exact types & dependencies

of the objects your code should work with.
2. Use the Factory Method when you want to provide users of
your library or framework with a way to extend its internal
components.
3. Use the Factory Method when you want to save system
resources by reusing existing objects instead of rebuilding
them each time.
 Factory Method: Implementation
1. Make all products follow the same interface. This interface should declare
methods that make sense in every product.
2. Add an empty factory method inside the creator class. The return type of
the method should match the common product interface.
3. In the creator’s code find all references to product constructors. One by
one, replace them with calls to the factory method, while extracting the
product creation code into the factory method.
4. Now, create a set of creator subclasses for each type of product listed in
the factory method. Override the factory method in the subclasses and
extract the appropriate bits of construction code from the base method.
5. If there are too many product types and it doesn’t make sense to create
subclasses for all of them, you can reuse the control parameter from the
base class in subclasses.
6. If, after all of the extractions, the base factory method has become empty,
you can make it abstract. If there’s something left, you can make it a
default behavior of the method.
 Case Study
Using Factory Method for creating cross-platform UI
elements without coupling the client code to concrete UI
classes.

Problem:
● The base dialog class uses different UI elements to
render its window. Under various operating systems,
these elements may look a little bit different, but they
should still behave consistently. A button in Windows is
still a button in Linux.
Solution:
➔ You don’t need to rewrite the logic of the dialog for
each operating system.
➔ If we declare a factory method that produces buttons
inside the base dialog class, we can later create a
dialog subclass that returns Windows-styled buttons
from the factory method.
➔ The subclass then inherits most of the dialog’s code
from the base class, but, thanks to the factory method,
can render Windows-looking buttons on the screen.
➔ For this pattern to work, the base dialog class must
work with abstract buttons: a base class or an interface
that all concrete buttons follow.
➔ With each new factory method you add to the dialog,
you get closer to the Abstract Factory pattern.
 Factory Method: Consequences
• Pros:
– You avoid tight coupling between the creator and the
concrete products.
– Single Responsibility Principle
• You can move the product creation code into one place in the
program, making the code easier to support.
– Open/Closed Principle
• You can introduce new types of products into the program without
breaking existing client code.

• Cons
– The code may become more complicated since you need to introduce a lot of
new subclasses to implement the pattern. The best case scenario is when
you’re introducing the pattern into an existing hierarchy of creator classes.
 Factory Method: Related Patterns
1. Many designs start by using Factory Method (less complicated and more
customizable via subclasses) and evolve toward Abstract Factory,
Prototype, or Builder (more flexible, but more complicated).
2. Abstract Factory classes are often based on a set of Factory Methods, but
you can also use Prototype to compose the methods on these classes.
3. You can use Factory Method along with Iterator to let collection
subclasses return different types of iterators that are compatible with the
collections.
4. Prototype isn’t based on inheritance, so it doesn’t have its drawbacks. On
the other hand, Prototype requires a complicated initialization of the
cloned object. Factory Method is based on inheritance but doesn’t require
an initialization step.
5. Factory Method is a specialization of Template Method. At the same time,
a Factory Method may serve as a step in a large Template Method.
 Conclusions
• Creational design patterns are beneficial in
that they allow your software to tightly
control the way in which it constructs objects
• Separate users of the code from the messy
details of creating and building objects
 Conclusions
• Abstract Factory:
– Lets you choose what family of products to create
at runtime
– Isolates the implementation from clients, since
clients only use the interfaces
– Makes exchanging product families simple
 Conclusions
• Factory Method:
– Defer object creation to subclasses via “hook”
methods and overriding
– Creation code need not know about specific
subclasses
Questions?