Factory vs Abstract Factory vs Builder - When to Use Each

▶

Steps

setup

Define Product Class: House

The House class is defined to represent the complex object being built. It contains a list of parts and methods to add parts and display the house composition.

💡 Defining the product class is essential because it represents the final object that the builder will construct step-by-step.

Line:

class House:
    def __init__(self):
        self.parts = []

💡 The product class holds the components that will be assembled by the builder.

setup

Define Builder Interface: HouseBuilder

The HouseBuilder class is defined as the builder interface specifying methods to build parts of the House. It initializes a House instance to assemble.

💡 The builder interface abstracts the construction steps, allowing different builders to implement them differently.

Line:

class HouseBuilder:
    def __init__(self):
        self.house = House()

💡 Builder holds a reference to the product and defines construction methods.

fill_cells

Implement build_walls Method

The build_walls method is implemented to add 'Walls' to the House parts list by calling the House's add method.

💡 Each build method corresponds to adding a specific part to the product, showing modular construction.

Line:

def build_walls(self):
    self.house.add("Walls")

💡 This step shows how the builder delegates part addition to the product.

fill_cells

Implement build_roof Method

The build_roof method is implemented to add 'Roof' to the House parts list by calling the House's add method.

💡 Adding the roof part demonstrates how the builder can add multiple distinct parts modularly.

Line:

def build_roof(self):
    self.house.add("Roof")

💡 Each build method corresponds to a part, enabling flexible product assembly.

fill_cells

Implement build_pool Method

The build_pool method is implemented to add 'Pool' to the House parts list by calling the House's add method.

💡 Adding an optional part like a pool shows how the builder can customize the product.

Line:

def build_pool(self):
    self.house.add("Pool")

💡 Builder methods enable flexible and optional parts to be added.

fill_cells

Implement get_result Method

The get_result method returns the fully constructed House object from the builder.

💡 This method provides access to the final product after construction is complete.

Line:

def get_result(self):
    return self.house

💡 The builder encapsulates product creation and exposes the final product via this method.

setup

Define Director Class

The Director class is defined to control the building process using a builder instance. It has methods to construct different types of houses.

💡 The director abstracts the construction sequence, allowing clients to build complex objects without knowing details.

Line:

class Director:
    def __init__(self, builder):
        self.builder = builder

💡 Director holds a builder and orchestrates construction steps.

construct

Director Constructs Basic House

The director calls builder methods to build walls and roof, constructing a basic house.

💡 This step shows how the director sequences builder calls to create a specific product variant.

Line:

def construct_basic_house(self):
    self.builder.build_walls()
    self.builder.build_roof()

💡 Director defines construction order and product configuration.

construct

Director Constructs Luxury House

The director calls builder methods to build walls, roof, and pool, constructing a luxury house with an additional feature.

💡 This step demonstrates how the director can extend construction sequences to create more complex products.

Line:

def construct_luxury_house(self):
    self.builder.build_walls()
    self.builder.build_roof()
    self.builder.build_pool()

💡 Adding extra builder calls enables product customization and complexity.

reconstruct

Client Retrieves Constructed House

The client calls get_result on the builder to retrieve the fully constructed House object after the director finishes construction.

💡 This step shows how the client obtains the final product after the building process is complete.

Line:

house = builder.get_result()

💡 The builder pattern separates construction from representation, allowing the client to get the product when ready.

reconstruct

Print Constructed House Parts

The client prints the House object, which calls the __str__ method to display the list of parts assembled.

💡 This final step confirms the product was built correctly with all intended parts.

Line:

print(house)

💡 The product's string representation shows the result of the stepwise construction.

class House:
    def __init__(self):  # STEP 1
        self.parts = []

    def add(self, part):  # STEP 3-5
        self.parts.append(part)

    def __str__(self):  # STEP 11
        return "House parts: " + ", ".join(self.parts)

class HouseBuilder:
    def __init__(self):  # STEP 2
        self.house = House()

    def build_walls(self):  # STEP 3
        self.house.add("Walls")

    def build_roof(self):  # STEP 4
        self.house.add("Roof")

    def build_pool(self):  # STEP 5
        self.house.add("Pool")

    def get_result(self):  # STEP 6, 10
        return self.house

class Director:
    def __init__(self, builder):  # STEP 7
        self.builder = builder

    def construct_basic_house(self):  # STEP 8
        self.builder.build_walls()
        self.builder.build_roof()

    def construct_luxury_house(self):  # STEP 9
        self.builder.build_walls()
        self.builder.build_roof()
        self.builder.build_pool()

if __name__ == "__main__":
    builder = HouseBuilder()  # STEP 2
    director = Director(builder)  # STEP 7
    director.construct_luxury_house()  # STEP 9
    house = builder.get_result()  # STEP 10
    print(house)  # STEP 11

📊

Factory vs Abstract Factory vs Builder - When to Use Each - Watch the Algorithm Execute, Step by Step

Watching each step reveals how the Builder pattern separates construction from representation, making complex object creation manageable and flexible.

Defines the product class that will be built stepwise.

House

−parts: List[str]

+__init__()

+add()

+__str__()

Builder interface holds and constructs the product.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+__init__()

+build_walls()

+build_roof()

+2 more

HouseBuilder ◆ House (1:1)

Builder method adds a specific part to the product.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+build_walls()

HouseBuilder ◆ House (1:1)

Builder method adds another specific part to the product.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+build_roof()

HouseBuilder ◆ House (1:1)

Builder method adds an optional part to the product.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+build_pool()

HouseBuilder ◆ House (1:1)

Builder exposes the final product after construction.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+get_result()

HouseBuilder ◆ House (1:1)

Director controls the building process using a builder.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+build_walls()

+build_roof()

+build_pool()

+1 more

Director

−builder: HouseBuilder

+__init__()

+construct_basic_house()

+construct_luxury_house()

HouseBuilder ◆ House (1:1)Director ◇ HouseBuilder (1:1)

Director sequences builder calls to create a basic product.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+build_walls()

+build_roof()

Director

−builder: HouseBuilder

+construct_basic_house()

HouseBuilder ◆ House (1:1)Director ◇ HouseBuilder (1:1)

Director sequences builder calls to create a luxury product.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+build_walls()

+build_roof()

+build_pool()

Director

−builder: HouseBuilder

+construct_luxury_house()

HouseBuilder ◆ House (1:1)Director ◇ HouseBuilder (1:1)

Client retrieves the constructed product from the builder.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

+get_result()

Director

−builder: HouseBuilder

HouseBuilder ◆ House (1:1)Director ◇ HouseBuilder (1:1)

Product displays its assembled parts confirming construction.

House

−parts: List[str]

+__init__()

+add()

+__str__()

HouseBuilder

−house: House

Director

−builder: HouseBuilder

HouseBuilder ◆ House (1:1)Director ◇ HouseBuilder (1:1)

Key Takeaways

✓ Builder pattern separates complex object construction from its representation.

This separation is hard to grasp from code alone but becomes clear when watching stepwise construction.

✓ Director controls the construction sequence, enabling different product variants.

Seeing the director call different builder methods clarifies how product complexity and customization are managed.

✓ Builder methods modularly add parts, allowing optional features to be included flexibly.

Watching each part addition step reveals how optional components like pools are integrated without changing the product class.

Practice

1. Trace the sequence of events when a player rolls the dice and lands on a ladder in a well-designed Snake and Ladder game. Which of the following best describes the correct order of internal state changes?

easy

A. Player rolls dice -> GameController calculates new position -> Board checks for ladder -> GameController updates Player position accordingly

B. Player rolls dice -> Player position updated -> Board checks for ladder -> Player position updated again if ladder found

C. Player rolls dice -> Board updates Player position directly if ladder found -> Player notified of new position

D. Player rolls dice -> Dice notifies Board -> Board updates Player position -> GameController confirms move

Solution

1. Step 1: Dice roll triggers GameController

   Dice generates number; GameController uses it to calculate tentative position.

2. Step 2: Board checks for ladder or snake

   GameController queries Board to see if new position has ladder or snake.

3. Step 3: GameController updates Player position

   Based on Board's info, GameController updates Player's position accordingly.

4. Step 4: Player position is finalized

   Player's position reflects ladder climb if applicable.

5. Final Answer:

   Option A -> Option A

6. Quick Check:

   Only GameController manages state changes; Board is queried but does not update Player directly.

Hint: GameController mediates all state changes after dice roll [OK]

Common Mistakes:

• Assuming Player updates position before Board check
• Believing Board directly updates Player position
• Thinking Dice notifies Board

2. In a large software system, when would applying the Interface Segregation Principle (ISP) be most beneficial?

easy

A. When clients depend on interfaces that contain methods they do not use, causing unnecessary implementation burden.

B. When all clients require the exact same set of methods, so a single fat interface simplifies design.

C. When you want to enforce a strict inheritance hierarchy with minimal interfaces.

D. When you want to reduce the number of interfaces to simplify the codebase.

Solution

1. Step 1: Understand ISP's goal

   ISP aims to prevent clients from depending on methods they don't use, avoiding fat interfaces that force unnecessary implementations.

2. Step 2: Analyze options

   When clients depend on interfaces that contain methods they do not use, causing unnecessary implementation burden. correctly identifies the scenario where ISP helps by splitting fat interfaces. When all clients require the exact same set of methods, so a single fat interface simplifies design. describes a scenario where ISP is less needed. When you want to enforce a strict inheritance hierarchy with minimal interfaces. confuses inheritance hierarchy with interface segregation. When you want to reduce the number of interfaces to simplify the codebase. incorrectly assumes fewer interfaces always simplify design, ignoring interface misuse.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   ISP is about splitting interfaces to avoid forcing clients to implement unused methods.

Hint: ISP splits interfaces so clients only depend on what they use.

Common Mistakes:

• Believing fewer interfaces always mean better design
• Thinking ISP applies when all clients use all methods
• Confusing ISP with inheritance hierarchy rules

3. Examine the following buggy CompositeIterator code snippet. Which line contains the subtle bug that causes incorrect traversal order?

medium

A. Line initializing self.stack without reversing children.

B. Line checking hasNext() before popping from stack.

C. Line popping component from stack.

D. Line returning the component after processing.

Solution

1. Step 1: Identify stack initialization issue

   Stack is initialized with children in original order, not reversed, causing traversal order reversal.

2. Step 2: Confirm impact on traversal order

   Without reversing, popping from stack yields children in reverse order, breaking expected traversal.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Reversing children on stack initialization fixes traversal order [OK]

Hint: Stack must reverse children to preserve traversal order [OK]

Common Mistakes:

• Forgetting to reverse children on stack push
• Misplacing hasNext() check

4. Suppose you have a legacy system that violates the Open/Closed Principle by frequently modifying core classes for new features. What is the best strategy to refactor it to comply with OCP without breaking existing functionality?

hard

A. Replace all core classes with interfaces and rewrite all implementations from scratch

B. Use global variables to control behavior changes instead of modifying classes

C. Continue modifying core classes but add feature flags to isolate changes

D. Introduce abstract base classes or interfaces and create new subclasses for new features, leaving existing classes unchanged

Solution

1. Step 1: Understand refactoring goals

   Refactor to enable extension via new subclasses without modifying existing tested classes.

2. Step 2: Why introducing abstract base classes or interfaces and creating new subclasses for new features, leaving existing classes unchanged fits

   Introducing abstractions and subclassing allows adding features by extension, preserving existing code.

3. Step 3: Why other options fail

   Replace all core classes with interfaces and rewrite all implementations from scratch is costly and risky; Continue modifying core classes but add feature flags to isolate changes continues violating OCP; Use global variables to control behavior changes instead of modifying classes introduces global state, increasing complexity and bugs.

4. Final Answer:

   Option D -> Option D

5. Quick Check:

   Refactor by abstraction and extension, not rewrite or global state hacks.

Hint: Refactor with abstractions and subclasses, keep existing code intact [OK]

Common Mistakes:

• Thinking rewrite is the only way to comply with OCP
• Believing feature flags solve OCP violations
• Using global variables as a workaround

5. In a legacy system, a class handles both business logic and logging. You want to refactor it following SRP, but the logging code is tightly intertwined with business logic. What is the best approach to refactor this while respecting SRP?

hard

A. Ignore SRP in this case because legacy code should not be refactored.

B. Leave logging inside the class because extracting it would break existing functionality and increase risk.

C. Merge business logic and logging into a utility class to centralize all cross-cutting concerns.

D. Extract logging into a separate class and replace logging calls with calls to this new class, even if it requires modifying many places.

Solution

1. Step 1: Identify responsibilities

   Business logic and logging are separate reasons to change.

2. Step 2: Refactor strategy

   Extract logging into its own class to isolate changes related to logging.

3. Step 3: Address tight coupling

   Though intertwined, refactoring calls to the new logging class improves maintainability and respects SRP.

4. Step 4: Evaluate other options

   Options B and D avoid refactoring, risking future issues; C increases coupling by merging unrelated concerns.

5. Final Answer:

   Option D -> Option D

6. Quick Check:

   Extract and isolate responsibilities even if it requires effort -> SRP compliance.

Hint: Separate concerns even if intertwined; refactor stepwise.

Common Mistakes:

• Avoiding refactoring due to perceived risk.
• Merging unrelated concerns for convenience.
• Ignoring SRP in legacy code.