Mastering Factory Patterns for Decoupled Object Creation

1. The Core Problem: The Tight Coupling of new

In much of our code, we create objects directly: myObject = new MyObject(). While simple, this approach tightly couples the client code (the code that uses the object) to the concrete class (MyObject).

Imagine you're building an application that processes different types of documents: PDF, DOCX, TXT. Your code might look like this:

// A simplified example
if (fileType.equals("pdf")) {
    document = new PDFDocument();
} else if (fileType.equals("docx")) {
    document = new DOCXDocument();
} else {
    document = new TXTDocument();
}
document.process();

What happens when you need to add a CSVDocument? You have to find and modify this if/else block. If this logic is scattered in multiple places, the task becomes risky and tedious. This design violates the Open/Closed Principle: it's not open for extension without modification.

This is the exact problem factory patterns are designed to solve.

2. A First Step: The Simple Factory Idiom

A common first step to clean this up is to encapsulate the creation logic into a single, dedicated class. This is often called a "Simple Factory." While not an official design pattern, it's a crucial stepping stone.

The Simple Factory centralizes creation logic, which is an improvement (it follows the Single Responsibility Principle). However, the factory class itself must still be modified whenever a new product type is added. We can do better.

3. The Factory Method Pattern

The Factory Method pattern provides a complete solution. It defines an interface for creating an object but lets subclasses decide which class to instantiate.

How It Works

The key idea is to move from a single factory class to an abstract Creator class that declares a factoryMethod(). Concrete subclasses then override this method to produce specific products. This relies on inheritance.

Let's see how this is applied to the burger example.

Structure and Vocabulary

To formalize what you just saw, let's look at the standard terminology and structure of the pattern.

The structure can be visualized with a standard UML diagram.

With this pattern, adding a new ChickenBurger doesn't require modifying any existing code. You simply create a new ChickenBurger class (a ConcreteProduct) and a new ChickenBurgerRestaurant class (a ConcreteCreator). The system is now open for extension but closed for modification.

4. The Abstract Factory Pattern

The Factory Method is perfect for creating a single type of object. But what if your system needs to create families of related objects that are designed to work together?

For instance, imagine a UI toolkit that supports multiple operating systems (Windows, macOS). A theme for Windows should have a WindowsButton and a WindowsCheckbox. A theme for macOS should have a macOSButton and a macOSCheckbox. You must never mix them; a WindowsButton with a macOSCheckbox would break consistency.

This is where the Abstract Factory pattern shines. It provides an interface for creating families of related or dependent objects without specifying their concrete classes. It's like a "factory of factories."

How It Works

The Abstract Factory pattern introduces an AbstractFactory interface that declares a set of factory methods, one for each product in the family (e.g., createButton(), createCheckbox()). Concrete factories then implement this interface to produce a specific family of objects that are guaranteed to be compatible.

Use Cases and Structure

The Abstract Factory pattern is powerful for enforcing consistency across a set of objects. This is fundamental to building scalable, maintainable architectures.

5. Factory Method vs. Abstract Factory

It's easy to confuse these two patterns, but their intent is different. Here's a summary to help you distinguish them:

Often, the methods within an Abstract Factory are implemented as Factory Methods. The two patterns can work together.

Conclusion

You've now learned about two foundational creational patterns that are essential for building flexible and maintainable systems. By moving object creation out of your client code and into dedicated factories, you decouple your components and embrace the Open/Closed Principle—a cornerstone of good software architecture.

Key Takeaways:

• Directly calling new creates tight coupling and makes code hard to extend.
• Factory Method uses inheritance to let subclasses decide which single type of object to create, decoupling the client from the concrete product.
• Abstract Factory uses composition to provide an interface for creating families of related objects, ensuring they are compatible with each other.
• Choosing the right pattern depends on whether you are creating a single object or a consistent set of objects.

Preview of the Next Lesson:
We will continue our exploration of creational patterns by examining the Singleton pattern. It has a very different goal: ensuring that a class has only one instance and providing a global point of access to it. We will implement it and, just as importantly, evaluate its use cases and significant drawbacks.