Factory Design Pattern

Video Lecture

Section	Video Links
Factory Overview
Factory Use Case
ABCMeta Module

Overview

When developing code, you may instantiate objects directly in methods or in classes. While this is quite normal, you may want to add an extra abstraction between the creation of the object and where it is used in your project.

You can use the Factory pattern to add that extra abstraction. The Factory pattern is one of the easiest patterns to understand and implement.

Adding an extra abstraction will also allow you to dynamically choose classes to instantiate based on some kind of logic.

Before the abstraction, your client, class or method would directly instantiate an object of a class. After adding the factory abstraction, the concrete product (object) is no longer created in the current class/method, but in a subclass instead.

Imagine an application for designing houses and the house has a chair already added on the floor by default. By adding the factory pattern, you could give the option to the user to choose different chairs, and how many at runtime. Instead of the chair being hard coded into the project when it started, the user now has the option to choose.

Adding this extra abstraction also means that the complications of instantiating extra objects can now be hidden from the class or method that is using it.

This separation also makes your code easier to read and document.

The Factory pattern is really about adding that extra abstraction between the object creation and where it is used. This gives you extra options that you can more easily extend in the future.

Terminology

Concrete Creator: The client application, class or method that calls the Creator (Factory method).
Product Interface: The interface describing the attributes and methods that the Factory will require in order to create the final product/object.
Creator: The Factory class. Declares the Factory method that will return the object requested from it.
Concrete Product: The object returned from the Factory. The object implements the Product interface.

Factory UML Diagram

Factory Pattern Overview

Source Code

In this concept example, the client wants an object named b

Rather than creating b directly in the client, it asks the creator (factory) for the object instead.

The factory finds the relevant class using some kind of logic from the attributes of the request. It then asks the subclass to instantiate the new object that it then returns as a reference back to the client asking for it.

./factory/factory_concept.py

# pylint: disable=too-few-public-methods
# pylint: disable=arguments-differ
"The Factory Concept"
from abc import ABCMeta, abstractmethod

class IProduct(metaclass=ABCMeta):
    "A Hypothetical Class Interface (Product)"

    @staticmethod
    @abstractmethod
    def create_object():
        "An abstract interface method"

class ConcreteProductA(IProduct):
    "A Concrete Class that implements the IProduct interface"

    def __init__(self):
        self.name = "ConcreteProductA"

    def create_object(self):
        return self

class ConcreteProductB(IProduct):
    "A Concrete Class that implements the IProduct interface"

    def __init__(self):
        self.name = "ConcreteProductB"

    def create_object(self):
        return self

class ConcreteProductC(IProduct):
    "A Concrete Class that implements the IProduct interface"

    def __init__(self):
        self.name = "ConcreteProductC"

    def create_object(self):
        return self

class Creator:
    "The Factory Class"

    @staticmethod
    def create_object(some_property):
        "A static method to get a concrete product"
        if some_property == 'a':
            return ConcreteProductA()
        if some_property == 'b':
            return ConcreteProductB()
        if some_property == 'c':
            return ConcreteProductC()
        return None

# The Client
PRODUCT = Creator.create_object('b')
print(PRODUCT.name)

Output

python ./factory/factory_concept.py
ConcreteProductB

Factory Use Case

An example use case is a user interface where the user can select from a menu of items, such as chairs.

The user has been given a choice using some kind of navigation interface, and it is unknown what choice, or how many the user will make until the application is actually running, and the user starts using it.

So, when the user selected the chair, the factory then takes some property involved with that selection, such as an ID, Type or other attribute and then decides which relevant subclass to instantiate in order to return the appropriate object.

Factory Example UML Diagram

Chair Factory

Source Code

./factory/client.py

"Factory Use Case Example Code"

from chair_factory import ChairFactory

# The Client
CHAIR = ChairFactory.get_chair("SmallChair")
print(CHAIR.get_dimensions())

./factory/interface_chair.py

# pylint: disable=too-few-public-methods
"The Chair Interface"
from abc import ABCMeta, abstractmethod

class IChair(metaclass=ABCMeta):
    "The Chair Interface (Product)"

    @staticmethod
    @abstractmethod
    def get_dimensions():
        "A static interface method"

./factory/chair_factory.py

"The Factory Class"

from small_chair import SmallChair
from medium_chair import MediumChair
from big_chair import BigChair

class ChairFactory:  # pylint: disable=too-few-public-methods
    "The Factory Class"

    @staticmethod
    def get_chair(chair):
        "A static method to get a chair"
        if chair == 'BigChair':
            return BigChair()
        if chair == 'MediumChair':
            return MediumChair()
        if chair == 'SmallChair':
            return SmallChair()
        return None

./factory/small_chair.py

# pylint: disable=too-few-public-methods
"A Class of Chair"
from interface_chair import IChair

class SmallChair(IChair):
    "The Small Chair Concrete Class implements the IChair interface"

    def __init__(self):
        self._height = 40
        self._width = 40
        self._depth = 40

    def get_dimensions(self):
        return {
            "width": self._width,
            "depth": self._depth,
            "height": self._height
        }

./factory/medium_chair.py

# pylint: disable=too-few-public-methods
"A Class of Chair"
from interface_chair import IChair

class MediumChair(IChair):
    "The Medium Chair Concrete Class implements the IChair interface"

    def __init__(self):
        self._height = 60
        self._width = 60
        self._depth = 60

    def get_dimensions(self):
        return {
            "width": self._width,
            "depth": self._depth,
            "height": self._height
        }

./factory/big_chair.py

# pylint: disable=too-few-public-methods
"A Class of Chair"
from interface_chair import IChair

class BigChair(IChair):
    "The Big Chair Concrete Class implements the IChair interface"

    def __init__(self):
        self._height = 80
        self._width = 80
        self._depth = 80

    def get_dimensions(self):
        return {
            "width": self._width,
            "depth": self._depth,
            "height": self._height
        }

Output

python ./factory/client.py
{'width': 40, 'depth': 40, 'height': 40}

New Coding Concepts

ABCMeta

ABCMeta classes are a development tool that help you to write classes that conform to a specified interface that you've designed.

ABCMeta refers to Abstract Base Classes.

The benefits of using ABCMeta classes to create abstract classes is that your IDE and Pylint will indicate to you at development time whether your inheriting classes conform to the class definition that you've asked them to.

Abstract interfaces are not instantiated directly in your scripts, but instead implemented by subclasses that will provide the implementation code for the abstract interface methods. E.g., you don't create IChair, but you create SmallChair that implements the methods described in the IChair interface.

An abstract interface method is a method that is declared, but contains no implementation. The implementation happens at the class that inherits the abstract class.

You don't need to use ABCMeta classes and interfaces that you have created in your final Python code. Your code will still work without them.

You can try it by removing the interfaces from all the chair classes above, and you will see that your Python program will still run.

E.g., change

class BigChair(IChair):

to

class BigChair():

and it will still work.

While it is possible to ensure your classes are correct without using abstract classes, it is often easier to use abstract classes as a backup method of checking correctness, especially if your projects become very large and involve many developers.

Note that in all my code examples, the abstract classes are prefixed with a capital I, to indicate that they are abstract interfaces. They have no code in their methods. They do not require a self or cls argument due to the use of @staticmethod. The inheriting class will implement the code in each of the methods that the abstract class is describing. If subclasses are inheriting an abstract base class, and they do not implement the methods as described, there will be a Pylint error or warning message (E0110).

See PEP 3119 : https://www.python.org/dev/peps/pep-3119/

Summary

The Factory Pattern is an Interface that defers the creation of the final object to a subclass.
The Factory pattern is about inserting another layer/abstraction between instantiating an object and where in your code it is actually used.
It is unknown what or how many objects will need to be created until runtime.
You want to localize knowledge of the specifics of instantiating a particular object to the subclass so that the client doesn't need to be concerned about the details.
You want to create an external framework, that an application can import/reference, and hide the details of the specifics involved in creating the final object/product.
The unique factor that defines the Factory pattern, is that your project now defers the creation of objects to the subclass that the factory had delegated it to.

	Zabbix
	Grafana
	Prometheus
	Threejs and TypeScript
	SocketIO and TypeScript
	Blender Topological Earth
	Sweet Home 3D
	Design Patterns Python
	Design Patterns TypeScript

	Course Coupon Codes

Three.js and TypeScript
		Kindle Edition $6.99 $9.99 Paperback $22.99 $29.99
Design Patterns in TypeScript
		Kindle Edition $6.99 $9.99 Paperback $11.99 $19.99
Design Patterns in Python
		Kindle Edition $6.99 $9.99 Paperback $11.99 $19.99