Why creational patterns manage object creation in LLD - Architecture Impact

System Overview - Why creational patterns manage object creation

This system explains why creational design patterns are used to manage object creation in software design. The key goal is to control how objects are created to improve flexibility, reuse, and maintainability of code.

Architecture Diagram

User
  |
  v
Client Code
  |
  v
Creational Pattern Manager
  |
  +--> Object Factory
  |
  +--> Singleton Instance
  |
  +--> Builder
  |
  v
Created Objects

Components

User

actor

Initiates requests that require object creation

Client Code

component

Code that needs objects but delegates creation to patterns

Creational Pattern Manager

service

Central place managing object creation using patterns

Object Factory

service

Creates objects based on input parameters

Singleton Instance

service

Ensures only one instance of a class is created

Builder

service

Constructs complex objects step-by-step

Created Objects

resource

Objects produced by creational patterns for use

Request Flow - 7 Hops

User → Client Code

Client Code → Creational Pattern Manager

Creational Pattern Manager → Object Factory

Creational Pattern Manager → Singleton Instance

Creational Pattern Manager → Builder

Creational Pattern Manager → Client Code

Client Code → User

Failure Scenario

Component Fails:Creational Pattern Manager

Impact:Objects cannot be created or managed properly, causing application errors or crashes

Mitigation:Implement fallback default object creation in client code or use error handling to prevent crashes

Architecture Quiz - 3 Questions

Why does the client code delegate object creation to the Creational Pattern Manager?

A To avoid using objects altogether

B To centralize and control how objects are created

C To speed up user input

D To bypass object creation

Design Principle

This architecture shows how creational patterns centralize and control object creation to improve code flexibility, reuse, and maintainability by separating creation logic from usage.

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