Factory Method vs Abstract Factory — When to Use Each

The core distinction is scale. Factory Method handles one product type with multiple variants — a base class defines a createNotification() method, and subclasses override it to return an EmailNotification or PushNotification. The mechanism is inheritance: the subclass controls instantiation, the base class owns the algorithm.

Abstract Factory handles families of related products. A PaymentFactory interface declares createGateway(), createWebhookHandler(), and createRefundProcessor(). A StripeFactory implements all three, guaranteeing every product is Stripe-compatible. The mechanism is composition — the client holds a factory reference and delegates to it.

The critical value of Abstract Factory is consistency enforcement. Without it, nothing prevents a developer from wiring a StripeGateway with a PayPalWebhookHandler, which would fail at runtime. The factory ensures all products in the family come from the same source.

My practical rule: start with Factory Method when you have one varying product. Promote to Abstract Factory when two conditions appear — multiple related products that vary together, and incompatible combinations that need prevention. In Spring, FactoryBean is Factory Method — override getObject(). The ApplicationContext itself is a large Abstract Factory, producing beans, resources, and events as a coherent family. Don't reach for Abstract Factory if you have one product and two variants — that's over-engineering a solved problem.