Factory Method pattern in LLD - System Design Exercise

Design: Factory Method Pattern Implementation

Design and implement the Factory Method pattern focusing on class structure and object creation flow. Out of scope are concrete product implementations beyond simple examples and integration with external systems.

Functional Requirements

FR1: Create a system that allows creating objects without specifying the exact class of object to create.

FR2: Support adding new types of products without changing existing code.

FR3: Clients should use a common interface to create objects.

FR4: Ensure that object creation logic is encapsulated in factory classes.

Non-Functional Requirements

NFR1: The system should be easy to extend with new product types.

NFR2: Object creation should be decoupled from client code.

NFR3: The design should follow SOLID principles, especially Open/Closed Principle.

NFR4: The system should be simple and maintainable for small to medium scale applications.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Product interface or abstract class

Concrete product classes

Creator (factory) abstract class or interface

Concrete creator classes implementing the factory method

Design Patterns

Factory Method pattern

Abstract Factory pattern for more complex scenarios

Dependency Injection to decouple client and factory

Template Method pattern if creator has common steps

Reference Architecture

Client
  |
  v
Creator (abstract)
  |
  +---> ConcreteCreator1 -- creates --> ConcreteProduct1
  |
  +---> ConcreteCreator2 -- creates --> ConcreteProduct2

Product (interface/abstract)
  |
  +---> ConcreteProduct1
  |
  +---> ConcreteProduct2

Components

Product

Abstract class or interface

Defines the interface for objects the factory method creates.

ConcreteProduct

Concrete classes implementing Product

Specific implementations of the Product interface.

Creator

Abstract class or interface

Declares the factory method that returns Product objects.

ConcreteCreator

Concrete classes extending Creator

Overrides the factory method to instantiate specific ConcreteProduct.

Client

Any class using Creator

Uses Creator to get Product instances without knowing concrete classes.

Request Flow

1. Client calls the factory method on a Creator instance.

2. Creator's factory method is abstract or has a default implementation.

3. ConcreteCreator overrides the factory method to create and return a ConcreteProduct.

4. Client receives a Product interface reference and uses it without knowing the concrete type.

Database Schema

Not applicable for this design pattern as it focuses on class structure and object creation.

Scaling Discussion

Bottlenecks

Adding many product types can lead to many ConcreteCreator classes.

If product creation logic becomes complex, factory classes may grow large.

Client code may need to manage many factory instances if product variety is large.

Solutions

Use Abstract Factory pattern to group related factories and reduce class explosion.

Refactor complex creation logic into helper classes or use Builder pattern.

Use Dependency Injection to manage factory instances and simplify client code.

Interview Tips

Time: Spend 10 minutes explaining the problem and requirements, 15 minutes designing the class structure and flow, and 5 minutes discussing scaling and alternatives.

Explain the problem of object creation and why decoupling is important.

Describe the roles of Product, Creator, ConcreteProduct, and ConcreteCreator.

Show how the factory method encapsulates object creation.

Discuss how this pattern supports the Open/Closed Principle.

Mention when to use Factory Method vs Abstract Factory.

Talk about scaling challenges and how to address them.

Practice

1. What is the main purpose of the Factory Method pattern in system design?

easy

A. To enforce a single instance of a class throughout the application

B. To create objects directly without any abstraction

C. To define an interface for creating objects but let subclasses decide which class to instantiate

D. To provide a global point of access to a resource

Solution

1. Step 1: Understand the Factory Method pattern goal

   The Factory Method pattern aims to separate object creation from usage by defining an interface for creating objects.

2. Step 2: Identify the role of subclasses

   Subclasses decide which specific class to instantiate, allowing flexibility and easy extension.

3. Final Answer:

   To define an interface for creating objects but let subclasses decide which class to instantiate -> Option C

4. Quick Check:

   Factory Method = Interface for object creation + subclass decides [OK]

Hint: Factory Method lets subclasses choose object types [OK]

Common Mistakes:

• Confusing Factory Method with Singleton pattern
• Thinking Factory Method creates objects directly without abstraction
• Mixing Factory Method with global access patterns

2. Which of the following is the correct way to declare a Factory Method in an interface in a typical object-oriented design?

easy

A. public Product createProduct();

B. public static Product createProduct();

C. public void createProduct();

D. private Product createProduct();

Solution

1. Step 1: Understand Factory Method signature

   The Factory Method returns an object of a product type, so it must have a return type matching the product interface or class.

2. Step 2: Check access and static modifiers

   Factory Methods are usually instance methods (not static) and public to allow subclass overriding and usage.

3. Final Answer:

   public Product createProduct(); -> Option A

4. Quick Check:

   Factory Method returns product instance, public and non-static [OK]

Hint: Factory Method returns product, not void or static [OK]

Common Mistakes:

• Using void return type instead of product
• Making Factory Method static which breaks subclass override
• Declaring Factory Method private so subclasses can't override

3. Given the following code snippet, what will be the output?

abstract class Creator {
  abstract Product factoryMethod();
  void someOperation() {
    Product product = factoryMethod();
    print(product.operation());
  }
}

class ConcreteProductA implements Product {
  String operation() => "Product A operation";
}

class ConcreteCreatorA extends Creator {
  Product factoryMethod() => ConcreteProductA();
}

void main() {
  Creator creator = ConcreteCreatorA();
  creator.someOperation();
}

medium

A. Product operation

B. No output

C. Error: factoryMethod not implemented

D. Product A operation

Solution

1. Step 1: Trace the factoryMethod call in ConcreteCreatorA

   ConcreteCreatorA overrides factoryMethod to return ConcreteProductA instance.

2. Step 2: Call operation() on ConcreteProductA instance

   ConcreteProductA's operation() returns "Product A operation" which is printed.

3. Final Answer:

   Product A operation -> Option D

4. Quick Check:

   ConcreteCreatorA creates ConcreteProductA, prints its operation [OK]

Hint: Factory Method returns ConcreteProductA, prints its operation [OK]

Common Mistakes:

• Assuming abstract Creator can be instantiated
• Forgetting ConcreteCreatorA overrides factoryMethod
• Expecting generic Product operation output

4. Identify the error in the following Factory Method implementation:

abstract class Creator {
  Product factoryMethod();
}

class ConcreteCreator extends Creator {
  void factoryMethod() {
    print("Creating product");
  }
}

medium

A. ConcreteCreator's factoryMethod has wrong return type

B. Creator class should not be abstract

C. factoryMethod should be static

D. No error, code is correct

Solution

1. Step 1: Check method signature in abstract Creator

   factoryMethod returns Product type, so subclass must match return type.

2. Step 2: Check ConcreteCreator's factoryMethod signature

   It returns void, which conflicts with abstract method's Product return type.

3. Final Answer:

   ConcreteCreator's factoryMethod has wrong return type -> Option A

4. Quick Check:

   Return type mismatch causes error [OK]

Hint: Return type must match abstract method in subclass [OK]

Common Mistakes:

• Ignoring return type mismatch
• Thinking abstract class can't have abstract methods
• Assuming static needed for Factory Method

5. You are designing a system that supports multiple types of notifications: Email, SMS, and Push. Using the Factory Method pattern, how should you organize your classes to allow easy addition of new notification types without modifying existing code?

hard

A. Create separate unrelated classes for each notification type without a common interface

B. Create an abstract NotificationCreator with a factoryMethod returning Notification; implement subclasses EmailCreator, SMSCreator, PushCreator each creating respective Notification objects

C. Use static methods in Notification class to create different notification types

D. Create a single Notification class with if-else to handle all notification types

Solution

1. Step 1: Apply Factory Method pattern structure

   Define an abstract creator class with a factoryMethod that returns a Notification interface or abstract class.

2. Step 2: Implement concrete creators for each notification type

   Each subclass (EmailCreator, SMSCreator, PushCreator) overrides factoryMethod to create its specific Notification object.

3. Step 3: Ensure easy extension without modifying existing code

   Adding new notification types means adding new creator subclasses without changing existing ones, following open-closed principle.

4. Final Answer:

   Create an abstract NotificationCreator with a factoryMethod returning Notification; implement subclasses EmailCreator, SMSCreator, PushCreator each creating respective Notification objects -> Option B

5. Quick Check:

   Factory Method enables easy extension via subclassing [OK]

Hint: Use abstract creator + subclasses for each notification type [OK]

Common Mistakes:

• Using if-else inside one class, violating open-closed principle
• Using static methods, reducing flexibility
• Not using a common interface for notifications