Software Design Principles

05 Design Pattern– Part 2

Dr. Mostafa Elgendy
[Link]@[Link]
Agenda
▪ Prototype Pattern

▪ Factory Method Pattern

▪ Abstract Factory Pattern

▪ Summary

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 2

 Prototype Pattern

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 3

Prototype Pattern
▪ A creational design pattern that lets
you copy existing objects without
making your code dependent on their
classes

▪ Cloning of an existing object instead

of creating new one and can also be
customized as per the requirement.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 4

Problem
▪ Say you have an object, and you want to create a copy of it.

▪ First, you have to create a new object of the same class.

▪ Then you have to go through all the fields of the original object and
copy their values over to the new object

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 5

Problem
▪ But Not all objects can be copied that way because

▪ Some of the object’s fields may be private and not visible from
outside of the object itself.

▪ When it came from a third-party library.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 6

Solution
▪ The Prototype pattern delegates the cloning process to the
actual objects that are being cloned.

▪ The pattern declares a common interface for all objects that

support cloning.

▪ This interface lets you clone an object without coupling your code
to the class of that object.

▪ Usually, such an interface contains just a single clone method.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 7

Solution
▪ The implementation of the clone method is very similar in all
classes.

▪ The method creates an object of the current class and carries

over all of the field values of the old object into the new one.

▪ You can even copy private fields because most programming

languages let objects access private fields of other objects that
belong to the same class.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 8

Real-World Example1
▪ Suppose we have a master copy of a valuable document.

▪ We need to incorporate some changes to it to see the effect of the

change.

▪ In such a case, we can make a photocopy of the original document

and edit the changes.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 9

Real-World Example 2
▪ A group of people decide to celebrate the birthday of their friend Ron.
▪ They go to a bakery and buy a cake.

▪ To make it special, they request the seller to write, “Happy Birthday Ron” on the cake.

▪ From the seller’s point of view,

▪ He is not making any new model.

▪ He already defined the model and produces many cakes (which all look the same)
every day by following the same process,

▪ And finally makes each special with some small changes.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 10

Usage of Prototype Pattern
▪ When the classes are instantiated at runtime.

▪ When the cost of creating an object is expensive or

complicated.

▪ When the client application needs to be unaware of object

creation and representation.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 11

Structure - 1
▪ The Prototype interface
declares the cloning
methods.

▪ In most cases, it’s a single

clone method.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 12

Structure - 2
▪ The Concrete Prototype class
implements the cloning method.

▪ In addition to copying the original

object’s data to the clone.

▪ This method may also handle

some edge cases of the cloning
process related to cloning linked
objects, untangling recursive
dependencies, etc.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 13

Structure - 3
▪ The Client can produce a
copy of any object that
follows the prototype
interface.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 14

How to Implement 1
▪ Create the prototype interface and declare the clone method
in it. Or just add the method to all classes of an existing
class hierarchy, if you have one.

▪ A prototype class must define the alternative constructor that

accepts an object of that class as an argument.

▪ The constructor must copy the values of all fields defined in the class
from the passed object into the newly created instance.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 15

How to Implement 2
▪ If your programming language doesn’t support method overloading,
you won’t be able to create a separate “prototype” constructor.
▪ Copying the object’s data into the newly created clone will have to be performed
within the clone method.

▪ Having this code in a regular constructor is safer because the resulting object is
returned fully configured right after you call the new operator.

▪ The cloning method usually consists of just one line: running a new
operator with the prototypical version of the constructor.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 16

Example 1
▪ In this example, the Prototype pattern lets
you produce exact copies of geometric
objects, without coupling the code to their
classes.

▪ All shape classes follow the same

interface, which provides a cloning method.

▪ A subclass may call the parent’s cloning

method before copying its own field values
to the resulting object.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 17

Example 1

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 18

Example 1
▪ The cloning method creates a new object in
one go by calling the constructor of the
current class and passing the current object
as the constructor's argument.

▪ Performing all the actual copying in the

constructor helps to keep the result
consistent:
▪ The constructor will not return a result until the
new object is fully built; thus, no object can have
a reference to a partially-built clone.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 19

Example 1
▪ The cloning method creates a new object in
one go by calling the constructor of the
current class and passing the current object
as the constructor's argument.

▪ Performing all the actual copying in the

constructor helps to keep the result
consistent:
▪ The constructor will not return a result until the
new object is fully built; thus, no object can have
a reference to a partially-built clone.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 20

Prototype registry
▪ You could implement a centralized prototype
registry (or factory), which would contain a set of
pre-defined prototype objects.

▪ This way you could retrieve new objects from the

factory by passing its name or other parameters.

▪ The factory would search for an appropriate

prototype, clone it and return you a copy.

▪ Like if you have several database objects to

connect different databases

▪ You put them in a registry and selects the suitable one by

key

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 21

Prototype registry
▪ You could implement a centralized prototype
registry (or factory), which would contain a set of
pre-defined prototype objects.

▪ This way you could retrieve new objects from the

factory by passing its name or other parameters.

▪ The factory would search for an appropriate

prototype, clone it and return you a copy.

▪ Like if you have several database objects to

connect different databases

▪ You put them in a registry and selects the suitable one by

key

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 22

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 23

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 24

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 25

Shallow copy
▪ If you have a car object and want to
create a new object

▪ The newly created car reference the

same GpsSystem object in the
memory, and any change done in
this object will be reflected in both
cars
20-Mar-24 SOFTWARE DESIGN PRINCIPLES 26
Deep copy
▪ If you have a car object and want to
create a new object

▪ Any change on the first GpsSystem

object will not affect the second one

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 27

Example

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 28

Example

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 29

Example

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 30

Example

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 31

Example

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 32

 Factory Method Pattern

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 33

Factory Method Pattern
▪ Provides an interface for creating objects in a superclass but
allows subclasses to alter the type of objects that will be
created.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 34

Factory Method Pattern
▪ Imagine creating a logistics application.

▪ At first, the app can handle transportation by

trucks, so your code is inside the Truck class.

▪ After your app becomes popular.

▪ You receive requests from sea transportation

companies to incorporate sea logistics.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 35

Factory Method Pattern
▪ Adding Ships into the app require making
changes to the entire codebase.

▪ Moreover, if 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 nasty

code.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 36

Factory Method Pattern
▪ Factory Method pattern suggests that
you 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.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 37

Factory Method Pattern
▪ For example, both Truck and Ship classes should
implement the Transport interface, which
declares a method called deliver.

▪ Each class implements this method differently:

▪ Trucks deliver by land;

▪ Ships deliver by sea.

▪ The factory method in the RoadLogistics class

returns truck objects,

▪ The factory method in the SeaLogistics class

returns ships.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 38

How to implement
▪ Product declares the interface,
which is common to all objects that
can be produced by the creator and
its subclasses.

▪ Concrete Products are different

implementations of the product
interface.
20-Mar-24 SOFTWARE DESIGN PRINCIPLES 39
How to implement
▪ 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.

▪ You can declare the factory method as abstract to

force all subclasses to implement their own
versions of the method.

▪ Concrete Creators: override the base factory

method so it returns a different type of product.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 40

Example 1

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 41

Example 1

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 42

Example 1

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 43

Example 1

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 44

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 45

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 46

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 47

Example 3

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 48

Example 3

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 49

Example 3

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 50

Example 3

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 51

When to use 1
▪ Use the Factory Method when you don’t know the exact types of
the objects your code should work with.

▪ The Factory Method separates product construction code from the code
that actually uses the product. Therefore it’s easier to extend the product
construction code independently from the rest of the code.

▪ For example, to add a new product type to the app, you’ll only need to
create a new creator subclass and override the factory method in it.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 52

When to use 2
▪ When you want to provide users of your library with a way to
extend its internal components.

▪ The solution is to reduce the code that constructs components

across the framework into a single factory method and let anyone
override this method in addition to extending the component itself.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 53

 Abstract Factory Pattern

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 54

Abstract Factory Pattern
▪ Define an interface or abstract class for creating
families of related (or dependent) objects but without
specifying their concrete sub-classes.
▪ That means Abstract Factory lets a class
returns a factory of classes.
▪ So, this is the reason that Abstract Factory
Pattern is one level higher than the Factory
Pattern.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 55

Problem (1/3)
▪ Imagine that you’re creating a furniture
shop simulator:
▪ A family of related products, say: Chair + Sofa +
CoffeeTable.

▪ Several variants of this family. For example,

products Chair + Sofa + CoffeeTable are
available in these variants: Modern, Victorian,
ArtDeco.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 56

Problem (2/3)
▪ You need a way to create individual furniture objects so that they
match other objects of the same family.

▪ Customers get quite mad when they receive non-matching furniture.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 57

Problem (3/3)
▪ You don’t want to change code when adding new products or families of products.

▪ Vendors update their catalogs very often, and you wouldn’t want to change the core
code each time it happens.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 58

Solution (1/3)
▪ Explicitly declare interfaces for each distinct
product of the product family (e.g., chair, sofa
or coffee table).

▪ Then you can make all variants of products

follow those interfaces.
▪ For example, all chair variants can implement the
Chair interface; all coffee table variants can
implement the CoffeeTable interface, and so on..

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 59

Solution (2/3)
▪ Declare the Abstract Factory—an interface with a
list of creation methods for all products that are part
of the product family (for example, createChair,
createSofa and createCoffeeTable).

▪ These methods must return abstract product types

represented by the interfaces we extracted
previously: Chair, Sofa, CoffeeTable and so on.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 60

Solution (3/3)
▪ For each variant of a product family, we create a separate
factory class based on the AbstractFactory interface.

▪ A factory is a class that returns products of a particular kind.

▪ For example, the ModernFurnitureFactory can only create

ModernChair, ModernSofa and ModernCoffeeTable objects

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 61

How to implement (1/3)
▪ 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).

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 62

How to implement (2/3)
▪ Abstract Factory interface 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.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 63

How to implement (3/3)
▪ Although concrete factories instantiate concrete
products, signatures of their creation methods
must return corresponding abstract products.

▪ This way the client code that uses a factory

doesn’t get coupled to the specific variant of the
product it gets from a factory.

▪ The Client can work with any concrete

factory/product variant, as long as it
communicates with their objects via abstract
interfaces.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 64

Example 1
▪ Abstract Factory pattern can be used 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.

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 65

Example 1
▪ 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, it’s your job 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.

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

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 66

Example 1
▪ It works like this:

▪ 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 code uses this factory to create UI elements. This prevents the wrong elements from being created.

▪ With this approach,

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

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 67

Example 1

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 68

Example 1

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 69

Example 1

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 70

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 71

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 72

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 73

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 74

Example 2

20-Mar-24 SOFTWARE DESIGN PRINCIPLES 75

Summary
▪ Prototype Pattern

▪ Factory Method Pattern

▪ Abstract Factory Pattern

20-Mar-24 MOBILE PROGRAMMING 76

 Questions

20-Mar-24 MOBILE PROGRAMMING 77