Factory Method

Real-world analogy

A national postal and parcel logistics network operates delivery hubs across various terrains. Every hub executes the exact same core pipeline: scan package, verify weight, generate tracking manifest, and dispatch shipment. However, a coastal maritime hub creates cargo boat shipments, an airport hub creates air cargo flights, and a city center hub creates electric delivery vans. The core dispatch procedure is identical; only the vehicle object created for transport differs.

The problem

Consider an automated logistics and document notification system. In the initial release, the application only formats and transmits PDF invoices. Callers directly instantiate PDFDocument inside their core business workflows. When clients later demand HTML email invoices and plain-text receipts, developers add conditional branches directly inside the business service.

The naive code below demonstrates how object creation becomes tightly coupled to domain operations:

1 class InvoiceService {
2   generateInvoice(type, orderData) {
3     let document;
4     // Hard-wired conditionals: every new document type breaks this method!
5     if (type === "pdf") {
6       document = new PDFDocument();
7     } else if (type === "html") {
8       document = new HTMLDocument();
9     } else {
10       throw new Error(`Unsupported type: ${type}`);
11     }
12 
13     const payload = document.format(orderData);
14     console.log(`Auditing invoice generation for order: ${orderData.id}`);
15     return payload;
16   }
17 }
18 
19 class PDFDocument {
20   format(data) { return `<PDF>Invoice #${data.id}: $${data.total}</PDF>`; }
21 }
22 class HTMLDocument {
23   format(data) { return `<div>Invoice #${data.id}: $${data.total}</div>`; }
24 }
25 
26 const service = new InvoiceService();
27 console.log(service.generateInvoice("pdf", { id: 101, total: 250 }));

1 public class Example {
2   static class PDFDocument {
3     public String format(int id, double total) {
4       return "<PDF>Invoice #" + id + ": $" + total + "</PDF>";
5     }
6   }
7 
8   static class HTMLDocument {
9     public String format(int id, double total) {

Every time a new format is introduced (Markdown, XML, EDI), InvoiceService must be reopened and modified. Business logic and creation mechanics are tangled together, preventing callers from extending document generation independently.

The solution

Intent: Define an interface for creating an object, but let subclasses or specialized factory implementations decide which class to instantiate.

The participants are:

• Product: Declares the common interface for all objects created by the factory method.
• ConcreteProduct: Implements the Product interface with specific behavior.
• Creator: Declares the factory method returning a Product. May also implement a default template method that relies on the product.
• ConcreteCreator: Overrides the factory method to return an instance of a specific ConcreteProduct.

Step-by-step implementation

Step 1: Define the Product interface

Extract the common operations shared by all product variants into a unified contract.

Step 2: Declare the Creator with the factory method

Define an abstract base creator class whose business workflow relies on the factory method without knowing which concrete product is instantiated.

Step 3: Implement concrete creators

Each concrete creator subclass overrides the factory method to instantiate its specific product.

1 class PDFDocumentCreator extends DocumentCreator {
2+  createDocument() { 
3+    return new PDFDocument(); 
4+  } 
5 }
6 
7 class HTMLDocumentCreator extends DocumentCreator {
8+  createDocument() { 
9+    return new HTMLDocument(); 
10+  } 
11 }

The complete example

Here is a runnable document publishing engine. Notice how the client orchestrates invoicing through abstract creators, allowing new formats to be added without touching the engine.

1 PUBLISHED -> [PDF] Invoice #401 billed for $199.99
2 PUBLISHED -> <html><body>Invoice #402: $49.5</body></html>

Variations

1. Simple Factory (Static Factory)

A standalone helper class containing a static method with a switch or dictionary lookup:

1 public class DocumentFactory {
2   public static Document create(String type) {
3     if ("pdf".equalsIgnoreCase(type)) return new PDFDocument();
4     if ("html".equalsIgnoreCase(type)) return new HTMLDocument();
5     throw new IllegalArgumentException("Unknown type: " + type);
6   }
7 }

• Difference: Not a classic GoF pattern because it does not use subclassing, but very common in production code when subclassing creators is unnecessary overhead.

2. Registry-based Factory (Plugin pattern)

Instead of a hardcoded switch, creators register themselves into a lookup map dynamically:

1 class DocumentRegistry {
2   static #creators = new Map();
3   static register(type, creatorFn) {
4     this.#creators.set(type.toLowerCase(), creatorFn);
5   }
6   static create(type) {
7     const creator = this.#creators.get(type.toLowerCase());
8

• Pros: Completely satisfies the Open/Closed Principle: plugins can register new product types at application startup without editing the factory class.

3. Parameterized Factory Method

The creator's factory method takes an argument indicating which product variant to instantiate:

1 public abstract class DocumentPublisher {
2   public abstract Document createDocument(String levelOfDetail);
3 }

Where you've already used it

1. Java Standard Library (JDK):
   • java.util.Calendar.getInstance(): Returns a GregorianCalendar or JapaneseImperialCalendar based on JVM locale.
   • java.text.NumberFormat.getInstance(): Returns a locale-sensitive currency or decimal formatter.
   • java.nio.charset.Charset.forName(String): Returns the appropriate concrete encoding implementation.
2. Logging frameworks (SLF4J, Log4j):
   • org.slf4j.LoggerFactory.getLogger(Class): Creates a configured Logger binding depending on classpath adapters (Logback, Log4j2).
3. Browser and DOM APIs:
   • document.createElement("div"): Factory method creating concrete DOM element subclasses (HTMLDivElement, HTMLInputElement) behind the HTMLElement interface.
4. React and modern frontend:
   • React.createElement(type, props): Instantiates virtual DOM element descriptors based on component types or intrinsic HTML tags.

Pros and cons

When not to use it

If your application only has one concrete implementation of a product that is unlikely to change, do not introduce Factory Method. Direct instantiation is simpler and clearer. Adopt Factory Method when products vary across dimensions (environments, formats, platforms) or when framework callers need to configure which product is created.

Related patterns

Interview questions

Q1: What is the main structural difference between Simple Factory and Factory Method?
Simple Factory uses a single class with a conditional branch to instantiate products, meaning adding a new product requires modifying the factory class. Factory Method uses polymorphism and subclassing, allowing new products to be added via new creator subclasses without modifying existing code.

Q2: How does Factory Method relate to the Dependency Inversion Principle (DIP)?
High-level classes depend on the abstract Product interface rather than concrete product classes. The creator encapsulates the decision of which concrete class to instantiate, preventing high-level logic from directly coupling to low-level implementation details.

Q3: Can a Factory Method provide a default implementation?
Yes. In the GoF specification, the creator class can provide a default implementation of the factory method returning a standard product, allowing subclasses to override it only when they need a non-default product.

Q4: When should you prefer a Registry Factory over GoF subclassing?
Prefer a Registry Factory when product types are dynamic or loaded via plugins at runtime. Instead of creating a parallel class hierarchy of creators, products register a supplier lambda into a map, avoiding inheritance overhead.