Mahmoud Abas, Full-Stack Software Engineer & AI

System Design & Design Patterns - Part 1: Creational Design Patterns

In the print dialog, choose "Save as PDF" as the destination.

Part 1: Creational Design Patterns

Singleton, Factory, and Builder

Creational Patterns: Purpose

Deal with object creation mechanisms
Create objects in a manner suitable to the situation
Three patterns covered: Singleton, Factory, Builder
Each solves a different flavor of "how do I create this?"

Singleton Pattern: Intuition

Singleton: Ensures a class has only one instance and provides global access to it.

Structure: a private instance plus a getInstance() accessor
Guarantees every caller shares the same object

Singleton: When to Use

Database connection pools (expensive to create multiple)
Logging services (centralized logging)
Configuration managers (single source of truth)
Cache implementations (shared memory space)
Device drivers (hardware access control)

Singleton: Code Example

python

class DatabaseConnection:
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
            cls._instance.connection = None
        return cls._instance

    def connect(self):
        if self.connection is None:
            self.connection = "Connected to Database"
        return self.connection

db1 = DatabaseConnection()
db2 = DatabaseConnection()
print(db1 is db2)  # True - Same instance

call DatabaseConnection()

is _instance None?

create it once

always return that same _instance

Factory Pattern: Intuition

Factory: Creates objects without specifying their exact class, like a car factory producing different models from one process.

Decouples object creation from object usage
The caller asks for "a car," not for a specific class

Factory: When to Use

You don't know the exact class to instantiate until runtime
Creation logic is complex and should be centralized
You want to decouple object creation from usage
You have a family of related products
You need to enforce creation constraints

Factory: Code Example

python

class Animal(ABC):
    @abstractmethod
    def make_sound(self): pass

class Dog(Animal):
    def make_sound(self): return "Woof!"

class Cat(Animal):
    def make_sound(self): return "Meow!"

class AnimalFactory:
    @staticmethod
    def create_animal(animal_type):
        if animal_type == "dog":
            return Dog()
        elif animal_type == "cat":
            return Cat()

dog = AnimalFactory.create_animal("dog")
print(dog.make_sound())  # Woof!

Animal

abstract base

Dog

Cat

Factory: Real-World Example

GUI frameworks create OS-specific buttons through a factory
Example: WindowsButton vs MacButton, chosen at runtime
Common in cross-platform toolkits and plugin systems
The client code never hardcodes the concrete button class

Builder Pattern: Intuition

Builder: Constructs complex objects step by step, like building a house where you choose the rooms, materials, and options.

Separates the construction process from the final representation
Each step returns the builder itself, enabling a fluent chain

Builder: When to Use

Objects with many optional parameters (5+)
When a constructor would need too many parameters
When you want different representations of the same object
When construction is complex and multi-step
When you need immutable objects with many fields

Builder: Code Example

python

class PizzaBuilder:
    def __init__(self):
        self.pizza = Pizza()

    def set_size(self, size):
        self.pizza.size = size
        return self

    def add_topping(self, topping):
        self.pizza.toppings.append(topping)
        return self

    def build(self):
        return self.pizza

pizza = (PizzaBuilder()
         .set_size("Large")
         .add_topping("Pepperoni")
         .build())

.set_size()

.add_topping()

.build()

Pizza object

Key Takeaways

Singleton: one instance, global access, but easy to abuse into global state
Factory: decouples object creation from usage, picks the class at runtime
Builder: constructs complex objects step-by-step with a fluent, readable API
All three answer "how do I create this object cleanly?" from different angles
Pick Singleton for shared resources, Factory for type variability, Builder for many optional parameters

Open this lesson

Mahmoud AbasPart 1: Creational Design Patterns

class DatabaseConnection: _instance = None def __new__(cls): if cls._instance is None: cls._instance = super().__new__(cls) cls._instance.connection = None return cls._instance def connect(self): if self.connection is None: self.connection = "Connected to Database" return self.connection db1 = DatabaseConnection() db2 = DatabaseConnection() print(db1 is db2) # True - Same instance

class Animal(ABC): @abstractmethod def make_sound(self): pass class Dog(Animal): def make_sound(self): return "Woof!" class Cat(Animal): def make_sound(self): return "Meow!" class AnimalFactory: @staticmethod def create_animal(animal_type): if animal_type == "dog": return Dog() elif animal_type == "cat": return Cat() dog = AnimalFactory.create_animal("dog") print(dog.make_sound()) # Woof!

class PizzaBuilder: def __init__(self): self.pizza = Pizza() def set_size(self, size): self.pizza.size = size return self def add_topping(self, topping): self.pizza.toppings.append(topping) return self def build(self): return self.pizza pizza = (PizzaBuilder() .set_size("Large") .add_topping("Pepperoni") .build())