Why creational patterns manage object creation in LLD - Why This Architecture

Problem Statement

When object creation is scattered and uncontrolled, the code becomes hard to maintain and extend. This leads to duplicated code, tight coupling, and difficulty in managing complex object setups.

Solution

Creational patterns centralize and abstract the process of creating objects. They provide flexible ways to instantiate objects, allowing changes in creation logic without affecting the rest of the code.

Architecture

Client Code

→Creator/Factory

↓

Product/Object

Product/Object

This diagram shows how client code requests object creation from a centralized factory or creator, which then produces the desired object.

Trade-offs

✓ Pros

→

Reduces code duplication by centralizing object creation logic.

→

Improves code flexibility by decoupling object creation from usage.

→

Makes it easier to manage complex creation processes or configurations.

→

Supports changing object types without modifying client code.

✗ Cons

→

Adds an extra layer of abstraction, which can increase complexity for simple cases.

→

May introduce more classes or interfaces, increasing codebase size.

→

Improper use can lead to over-engineering when simple instantiation suffices.

Use when object creation is complex, involves multiple steps, or when the system needs to support different types of objects dynamically.

Avoid when object creation is straightforward and unlikely to change, especially in small or simple applications.

Real World Examples

Amazon

Uses factory patterns to create different types of payment processors dynamically based on user selection.

Netflix

Applies builder patterns to construct complex streaming session objects with multiple configuration options.

Uber

Employs singleton and factory patterns to manage shared resources like location services and ride request handlers.

Code Example

The before code creates Car objects directly wherever needed, causing duplication and tight coupling. The after code centralizes creation in CarFactory, making it easier to manage and extend car types without changing client code.

LLD

### Before: Direct instantiation scattered in code
class Car:
    def __init__(self, model):
        self.model = model

car1 = Car('Sedan')
car2 = Car('SUV')

### After: Using Factory pattern to manage creation
class Car:
    def __init__(self, model):
        self.model = model

class CarFactory:
    @staticmethod
    def create_car(car_type):
        if car_type == 'Sedan':
            return Car('Sedan')
        elif car_type == 'SUV':
            return Car('SUV')
        else:
            raise ValueError('Unknown car type')

car1 = CarFactory.create_car('Sedan')
car2 = CarFactory.create_car('SUV')

Alternatives

Direct Instantiation

Objects are created directly using constructors without abstraction.

Use when: When object creation is simple and unlikely to change.

Prototype Pattern

Creates new objects by cloning existing ones instead of building from scratch.

Use when: When object creation is costly and many similar objects are needed.

Summary

Uncontrolled object creation leads to duplicated and hard-to-maintain code.

Creational patterns centralize and abstract object creation to improve flexibility.

They help manage complex creation logic and support changing requirements easily.