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.