Why creational patterns manage object creation in LLD - Design It to Understand It

Design: Object Creation Management System

Focus on managing how objects are created in software design. Out of scope are object usage details and business logic unrelated to creation.

Functional Requirements

FR1: Create objects in a controlled and flexible way

FR2: Allow easy changes to the object creation process without affecting other parts of the system

FR3: Support different types of objects with varying configurations

FR4: Improve code reuse and reduce duplication in object creation

FR5: Ensure objects are created efficiently and correctly

Non-Functional Requirements

NFR1: Must handle creation of multiple object types

NFR2: Should minimize tight coupling between object creation and usage

NFR3: Creation process should be easy to maintain and extend

NFR4: Performance impact of object creation should be minimal

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Factory classes or methods

Builder components for step-by-step object construction

Singleton managers for single instance control

Prototype cloning mechanisms

Design Patterns

Factory Method

Abstract Factory

Builder

Singleton

Prototype

Reference Architecture

Client
  |
  | uses
  v
Creator (Factory/Builder)
  |
  | creates
  v
Product (Object)

Components

Client

Any programming language

Requests objects without knowing creation details

Creator (Factory or Builder)

Design pattern implementation

Encapsulates object creation logic and configuration

Product (Object)

Domain-specific classes

The objects created and used by the system

Request Flow

1. Client requests an object from the Creator.

2. Creator decides which concrete object to create based on input or configuration.

3. Creator constructs the object, possibly in multiple steps (Builder) or by cloning (Prototype).

4. Creator returns the fully constructed object to the Client.

5. Client uses the object without knowing how it was created.

Database Schema

Not applicable as this is a design pattern concept focusing on object creation, not data storage.

Scaling Discussion

Bottlenecks

Complex object creation logic can slow down system startup or runtime.

Too many object types can make factory code hard to maintain.

Singleton pattern can cause bottlenecks if overused and accessed concurrently.

Prototype cloning may be expensive if objects are large or complex.

Solutions

Use lazy initialization to create objects only when needed.

Modularize factory code and use configuration files to manage types.

Limit singleton usage to truly global resources and use thread-safe implementations.

Optimize cloning by shallow copying or using object pools.

Interview Tips

Time: Spend 10 minutes explaining the problem of object creation and why control is needed, 15 minutes describing key creational patterns and their use cases, and 5 minutes discussing scaling and maintenance considerations.

Explain how creational patterns separate object creation from usage.

Discuss benefits like flexibility, maintainability, and code reuse.

Describe common patterns and when to use each.

Mention potential performance impacts and how to mitigate them.

Show understanding of real-world scenarios where these patterns help.

Practice

1. Why do creational design patterns manage object creation in software design?

easy

A. To separate the process of creating objects from their usage, improving flexibility

B. To make the code run faster by avoiding object creation

C. To reduce the number of objects created to save memory

D. To enforce strict typing of objects in the system

Solution

1. Step 1: Understand the purpose of creational patterns

   Creational patterns focus on how objects are created, aiming to separate creation from usage.

2. Step 2: Identify the benefit of this separation

   This separation allows the system to be more flexible and easier to maintain or extend.

3. Final Answer:

   To separate the process of creating objects from their usage, improving flexibility -> Option A

4. Quick Check:

   Object creation separation = Flexibility [OK]

Hint: Creational patterns separate creation from use for flexibility [OK]

Common Mistakes:

• Thinking creational patterns only improve speed
• Confusing object creation with memory optimization
• Assuming creational patterns enforce type rules

2. Which of the following is the correct syntax to implement a simple Factory Method pattern in Python?

easy

A. def Factory():
return Product()

B. class Factory:
def create(self):
return Product()

C. class Factory:
def create():
return Product()

D. class Factory:
def create(self):
return Product

Solution

1. Step 1: Check method definition with self parameter

   In Python, instance methods must have 'self' as the first parameter.

2. Step 2: Verify the method returns an instance, not a class

   The method should return an instance of Product, so 'Product()' is correct, not 'Product'.

3. Final Answer:

   class Factory: def create(self): return Product() -> Option B

4. Quick Check:

   Method with self and returns instance = class Factory: def create(self): return Product() [OK]

Hint: Instance methods need 'self' and return object instances [OK]

Common Mistakes:

• Omitting 'self' in method definition
• Returning class instead of instance
• Defining method without parameters

3. Given the following code snippet implementing a Singleton pattern, what will be the output?

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

obj1 = Singleton()
obj2 = Singleton()
print(obj1 is obj2)

medium

A. False

B. Error

C. True

D. None

Solution

1. Step 1: Understand Singleton __new__ method behavior

   The __new__ method ensures only one instance is created by storing it in _instance.

2. Step 2: Check if obj1 and obj2 refer to the same instance

   Both obj1 and obj2 call Singleton(), which returns the same _instance object.

3. Final Answer:

   True -> Option C

4. Quick Check:

   Singleton returns same instance = True [OK]

Hint: Singleton returns same object, so 'is' comparison is True [OK]

Common Mistakes:

• Assuming new instance created each call
• Confusing 'is' with '=='
• Expecting None or error output

4. Identify the error in the following Builder pattern implementation snippet:

class Builder:
    def __init__(self):
        self.product = Product()
    def build_part(self):
        self.product.add('part')
    def get_product(self):
        return self.product

builder = Builder()
builder.build_part()
product = builder.get_product()
print(product.parts)

medium

A. print statement syntax is incorrect

B. build_part method does not add parts correctly

C. get_product method returns None instead of product

D. Product class is not defined, causing a NameError

Solution

1. Step 1: Check for class definitions used

   The code uses 'Product' but does not define it anywhere, leading to NameError.

2. Step 2: Verify other method correctness

   Methods build_part and get_product are syntactically correct assuming Product exists.

3. Final Answer:

   Product class is not defined, causing a NameError -> Option D

4. Quick Check:

   Undefined Product class = NameError [OK]

Hint: Undefined classes cause NameError, check all class definitions [OK]

Common Mistakes:

• Assuming Product class exists by default
• Blaming method logic instead of missing class
• Ignoring error messages

5. In a large system, why is it beneficial to use creational patterns like Abstract Factory instead of directly instantiating objects with new or constructors?

hard

A. It allows the system to create families of related objects without specifying their concrete classes

B. It guarantees the system uses less memory by reusing objects automatically

C. It forces all objects to be created at compile time for faster execution

D. It removes the need for interfaces or abstract classes in the design

Solution

1. Step 1: Understand Abstract Factory pattern purpose

   This pattern provides an interface to create families of related objects without specifying their concrete classes.

2. Step 2: Analyze benefits in large systems

   It improves scalability and flexibility by decoupling object creation from usage and allowing easy swapping of object families.

3. Final Answer:

   It allows the system to create families of related objects without specifying their concrete classes -> Option A

4. Quick Check:

   Abstract Factory = Create related objects flexibly [OK]

Hint: Abstract Factory creates related objects without concrete classes [OK]

Common Mistakes:

• Thinking it reduces memory automatically
• Believing it forces compile-time creation
• Assuming it removes need for interfaces