Factory Method Pattern: Clear Explanation, Code Example, and Real-World Scenarios

What is the Factory Method pattern?

Uses a factory class to create objects so callers do not need to know how an object is instantiated; they request the desired product from the factory.

Goal: separate object creation from business logic, facilitating extension and reducing coupling.

Real‑world analogies

Tea shop: barista (factory) prepares different flavored teas (products) based on customer request.

Software: push‑notification module creates Android or iOS messages depending on device type.

Stationery factory: produces pens, pencils, etc., on demand.

Java implementation

1. Abstract product (unified product specification)

// Abstract product: Drink
public interface Drink {
    void showName();
}

2. Concrete products

// Product 1: Coke
public class Coke implements Drink {
    @Override
    public void showName() {
        System.out.println("Output: Coke");
    }
}

// Product 2: Juice
public class Juice implements Drink {
    @Override
    public void showName() {
        System.out.println("Output: Juice");
    }
}

3. Abstract factory (unified factory specification)

// Abstract factory
public interface DrinkFactory {
    Drink createDrink();
}

4. Concrete factories

// Coke factory
public class CokeFactory implements DrinkFactory {
    @Override
    public Drink createDrink() {
        return new Coke();
    }
}

// Juice factory
public class JuiceFactory implements DrinkFactory {
    @Override
    public Drink createDrink() {
        return new Juice();
    }
}

5. Test invocation

public class Test {
    public static void main(String[] args) {
        DrinkFactory factory1 = new CokeFactory();
        Drink drink1 = factory1.createDrink();
        drink1.showName();

        DrinkFactory factory2 = new JuiceFactory();
        Drink drink2 = factory2.createDrink();
        drink2.showName();
    }
}

Common business scenarios

Complex object‑creation logic repeated in many places.

Batch generation of objects of the same family but different variants (e.g., various payment methods, message types).

Product lines that evolve; new products can be added without modifying existing code.

Frameworks that need to instantiate low‑level components or third‑party classes.

Multi‑platform adaptation: creating appropriate instances for different operating systems or devices.