Factory Method is most useful when one kind of product varies, but the caller should not own the creation logic.

What the pattern is trying to do

Define an interface for creating an object while letting subclasses or specialized factories decide which concrete product to return.

What force creates the need

Object creation varies by context, but callers should not be cluttered with construction branching or knowledge of concrete types.

How the pattern responds

Move creation logic into a dedicated method or factory role so the caller depends on abstraction instead of conditional construction.

How the moving parts fit together

A creator exposes a factory method, and concrete creators or implementations decide which product implementation is created.

Java example in the Order Management domain

package org.javaomnibus.ecommerce.gof.creational;

public interface PaymentGatewayFactory {
    PaymentGateway create();
}

public final class CardGatewayFactory implements PaymentGatewayFactory {
    @Override
    public PaymentGateway create() {
        return new CardPaymentGateway();
    }
}

public final class CheckoutService {
    private final PaymentGatewayFactory paymentGatewayFactory;

    public CheckoutService(PaymentGatewayFactory paymentGatewayFactory) {
        this.paymentGatewayFactory = paymentGatewayFactory;
    }

    public void authorize(Order order) {
        paymentGatewayFactory.create().authorize(order.total());
    }
}

Step by step

1. CheckoutService no longer knows which concrete gateway to construct.
2. Creation logic is isolated in the factory role.
3. That makes variation easier to extend without repeatedly editing the caller.
4. This is especially useful when construction is non-trivial or selection varies by context.

Where this pattern helps

• When one product type varies by environment, customer choice, or integration target
• When callers should depend on a stable contract instead of concrete implementations

When a simpler design is better

• When direct construction is simple and unlikely to vary
• When object creation is not the real design pain point

What this pattern costs

• Adds more types and indirection
• Can be overkill for stable and simple construction

How this fits today

Factory Method remains highly relevant in Java, especially around integration points, testable construction logic, and places where DI still needs a domain-specific creation decision.

Where teams get it wrong

Creating factories for objects that do not actually vary is a common way to add ceremony without improving the design.

Compare with nearby choices