The Factory Method Design Pattern
EP07 | System Design | LLD Series | #04
In software development, design patterns are essential tools to solve common problems in a reusable way. One of the most widely used patterns is the Factory Method Design Pattern, part of the creational design patterns family. It provides an interface to create objects in a super-class, but allows subclasses to alter the type of objects that will be created.
In this article, we will explore how the Factory Method pattern improves the design of software systems, why it’s essential, and how to handle its disadvantages. Additionally, we will look at real-world scenarios where this pattern can be effectively applied.
Why Do We Need the Factory Method Design Pattern?
When you’re building a system that requires creating instances of classes, you may encounter situations where the exact class of the object to be created may not be known until runtime. In such scenarios, using the new keyword to instantiate objects directly can become problematic as it couples your code tightly with specific classes, making it hard to maintain and scale.
The Factory Method Design Pattern provides a solution to this by creating a layer of abstraction between the client code and the instantiation logic. The client doesn’t need to know which specific class to instantiate. It delegates this responsibility to a Factory class that takes care of the object creation based on input parameters or conditions.
Example : The Journey of a Global Vehicle Manufacturer
Imagine a global vehicle manufacturing company, GlobalAuto, that produces different types of vehicles, like cars, trucks, and motorcycles. The company has several factories around the world, each specialized in manufacturing specific styles of vehicles.
For example:
The US factory produces vehicles designed for American roads, focusing on SUVs and pickup trucks.
The European factory manufactures smaller, fuel-efficient vehicles like compact cars and sedans.
The Asian factory produces vehicles tailored for dense city traffic, focusing on scooters and small cars.
The challenge is that each factory needs to produce different types of vehicles depending on the market’s demand, but the central headquarters doesn’t want to know the specific details of how each factory makes its vehicles.
To solve this problem, GlobalAuto decides to implement the Factory Method Design Pattern. This pattern will allow each factory to handle its own vehicle production while providing a common interface to interact with them.
Simple Implementation
Problems
Tight Coupling: The client code (in this case, the SimpleVehicleManufacturing class) is tightly coupled with the specific vehicle classes like Car, Truck, and Motorcycle. If we need to introduce new vehicle types, such as Scooter or ElectricCar, we would have to modify the client code to accommodate these new classes.
Scalability Issues: If we decide to open new factories in different regions (such as Europe or Asia), each with different vehicle specifications (like electric scooters or compact trucks), we would need to add new conditional logic in the client code for each region. This makes the system harder to maintain and extend.
Violation of Open/Closed Principle: The system violates the Open/Closed Principle from SOLID design principles, which states that a class should be open for extension but closed for modification. In this example, any time we want to add a new vehicle or modify how vehicles are created, we must change the client code.
Code Duplication: If every client of the Vehicle class is responsible for creating and managing different vehicle types, the same logic for assembly, test drive, and delivery is repeated everywhere.
Why We Need the Factory Method Design Pattern
To address the problems above, we can implement the Factory Method Design Pattern, which helps us achieve the following:
Decoupling: The client code (vehicle manufacturing headquarters) no longer needs to know about the specific classes of vehicles (like Car, Truck, Motorcycle). It interacts only with an abstract VehicleFactory, which handles the creation of vehicles. This makes it easy to introduce new vehicle types without modifying the client code.
Extensibility: We can add new factories (like USVehicleFactory, EuropeVehicleFactory, or AsiaVehicleFactory) and new vehicle types (like ElectricCar or Scooter) by simply creating new subclasses, without touching the client code.
Encapsulation of Creation Logic: The creation of vehicles is encapsulated in the respective factory classes. Each factory class handles its own region-specific vehicle production logic, so the headquarters can focus on managing the overall manufacturing process.
Adherence to SOLID Principles: By using the Factory Method, we adhere to the Open/Closed Principle, since we can extend the system by adding new vehicle types and factories without modifying existing code.
Factory Method : Step-by-Step Implementation
Step 1: Create a Vehicle Class
We’ll start by defining a common Vehicle class that represents all vehicles. The specific vehicle types (Car, Truck, Motorcycle) will extend this base class.
Step 2: Implement Concrete Vehicle Classes
Next, we create specific vehicle types, such as Cars, Trucks, and Motorcycles, each with its own configuration.
Step 3: Create the VehicleFactory Class
The VehicleFactory class defines the Factory Method createVehicle(), which will be implemented by the specialized factories to create vehicles. The manufactureVehicle() method calls the factory method but doesn’t know which specific type of vehicle it will get.
Step 4: Implement Concrete Factories for Each Region
Now we’ll create concrete factories for different regions (US, Europe, Asia), each handling its own vehicle production process based on local market needs.
Step 5: The Headquarters' Client Code
The headquarters doesn’t need to worry about the specific details of how vehicles are created. It can just interact with the VehicleFactory interface and let each region handle the production of vehicles based on their local requirements.
Output
Explanation of the Design
The VehicleFactory class defines a Factory Method called createVehicle(). The concrete factories (US, Europe, and Asia) implement this method to create specific types of vehicles, like Cars, Trucks, or Motorcycles.
The manufactureVehicle() method in the VehicleFactory handles the common steps of assembling, test-driving, and delivering the vehicle. However, it calls the createVehicle() method, which is defined by the subclasses, to determine the specific vehicle to create.
The USVehicleFactory, EuropeVehicleFactory, and AsiaVehicleFactory classes are responsible for creating vehicles that meet the needs of their respective regions, such as large trucks in the US or motorcycles in Asia.
Class Diagram
Benefits of the Factory Design Pattern
Loose Coupling: The Factory pattern decouples the client code from the concrete classes. The client only interacts with the interface or abstract class, making the code more flexible and maintainable.
Single Responsibility Principle (SRP): The Factory pattern adheres to SRP by delegating the object creation responsibility to a separate factory class, keeping the object creation code out of the client code.
Scalability: You can easily add new types of objects (like a new vehicle type) without modifying the client code. You simply modify the factory class to handle the new types.
Improved Code Readability: The pattern makes your code cleaner and more readable, as object creation is centralized and standardized.
Handles Complex Creation Logic: If object creation is complex (e.g., requiring several steps or configurations), the Factory can encapsulate this complexity, simplifying client code.
Disadvantages of the Factory Design Pattern
Increased Complexity: While the Factory pattern simplifies object creation, it introduces additional classes (the factory classes). For simple cases, this can unnecessarily complicate the code.
Tight Coupling to Factory: Although the client is decoupled from the concrete classes, it still has some dependence on the Factory class. If the Factory needs to be changed or replaced, modifications might be required in several parts of the code.
Difficulty in Testing: Factories can sometimes be difficult to test if they contain complex logic or dependencies, requiring additional mocks or stubs in unit tests.
When to Use the Factory Pattern
The Factory Design Pattern is ideal in the following situations:
When the class of the object to be created isn’t known until runtime.
When you want to centralize and manage object creation logic.
When you want to decouple client code from specific implementations.
When creating objects is a complex task and requires abstraction.
How to Handle Disadvantages of the Factory Design Pattern
Increased Complexity:
Solution: Only use the Factory Method pattern when flexibility is needed, especially in cases where the type of object is determined dynamically. For simple object creation, using the
newkeyword directly may be more appropriate. You can also consider using Simple Factory if you have fewer object types.
Additional Layer of Abstraction:
Solution: Maintain clear documentation and use descriptive names for factory classes and methods to ensure that the abstraction is understandable. Keep the creation logic straightforward to avoid unnecessary complexity.
Maintenance Overhead:
Solution: To avoid overwhelming maintenance, use a single centralized factory or employ the Abstract Factory pattern for managing complex systems. You can also use dependency injection frameworks (like Spring in Java) to automatically handle object creation, reducing the burden on factory classes.
Real-Life Scenarios for Using the Factory Method Pattern
User Interface Components: In a GUI application, you might have different types of buttons (WindowsButton, MacButton, LinuxButton) depending on the operating system. The Factory Method can dynamically create the correct button type based on the user's OS.
Database Connections: Depending on the database type (MySQL, PostgreSQL, SQLServer), the Factory Method can return different connection objects, abstracting the underlying implementation from the client.
Loggers: A logging framework might need to create different types of loggers (e.g., FileLogger, ConsoleLogger, CloudLogger) based on the environment or configuration. Using a factory method allows the system to switch between loggers without modifying the core logic.
Payment Gateways: In an e-commerce application, the system may need to process payments via different payment gateways (e.g., Stripe, PayPal, Square). A factory can create the appropriate payment processor based on the user’s choice or region.
Notification Services: If your application needs to send notifications via different channels (email, SMS, push notifications), the Factory Method can help create the appropriate notification service without tying the client code to a specific channel.
By employing the Factory Method pattern, these systems can be extended or modified more easily, as new classes (e.g., a new payment gateway or notification service) can be added without changing the core client logic.
Conclusion
The Factory Method Design Pattern is an excellent tool for decoupling the instantiation logic from the core business logic, making your system more flexible and adaptable to change. While it adds some complexity due to the abstraction it introduces, it provides a robust structure for applications that need to create objects dynamically. By carefully assessing the complexity of your system and employing strategies like centralization, documentation, and dependency injection, you can mitigate the downsides and take full advantage of this powerful design pattern.
The Factory Method is a practical solution for scenarios requiring flexibility in object creation, from user interface components to complex database connections and payment processing systems. Use it wisely, and it will help make your software more maintainable, scalable, and robust.