How does the Abstract Factory pattern differ from the Factory Method pattern, in both intent and mechanism?
answer
- one product vs. a family
- inheritance vs. composition
- subclass the creator vs. inject the factory
- factories often implemented with factory methods
- simple/static factory is neither
basics
~20 sFactory Method has one creation method for one product kind and varies it by subclassing the creator. Abstract Factory is an object with several creation methods covering a whole family of related products, and you vary it by swapping which factory object you pass in.
solid answer
~50 sIntent: Factory Method defers the instantiation of **one** product to subclasses — "let subclasses decide which class to instantiate". Abstract Factory provides an interface for creating **families of related products** so a whole set can be swapped consistently. Mechanism: Factory Method is inheritance-based — an abstract creator class calls its own overridable `createX()` from template-method-style logic, and each subclass overrides it. Abstract Factory is composition-based — the client holds a reference to a factory object and calls several creation methods on it; variation comes from injecting a different implementation, not from subclassing the client. They are complementary, not rivals: a concrete factory's individual creation methods are often just factory methods. Rule of thumb: one product kind and the varying logic lives inside a class hierarchy → Factory Method; several product kinds that must stay in the same variant and are chosen from outside → Abstract Factory.
go deeper
Give the headline: Factory Method = one product, chosen by subclassing; Abstract Factory = several related products, chosen by swapping a factory object.
Add the mechanism contrast (inheritance vs. composition), the consistency guarantee, and note that concrete factories are typically implemented using factory methods.
Discuss why inheritance-based variation causes hierarchy multiplication across orthogonal axes, and how injecting a factory keeps those axes independent; mention testability and Prototype-based factory implementations.
Frame both as answers to "where does the concrete-type decision live", compare against DI containers and service-locator/registry approaches, and note that in many modern codebases the container subsumes Factory Method entirely while Abstract Factory survives where family consistency is a real invariant.
### Definitions, so nothing is assumed **Factory Method.** A creator class declares a method that returns a product (`abstract Product createProduct()`), and its other methods use that product without knowing its concrete type. Subclasses of the creator override the method to return a different concrete product. Variation therefore rides on **inheritance**: you get a different product by using a different *subclass of the creator*. ``` abstract class Dialog { abstract Button createButton() // the factory method void render() { // logic written against the abstract product Button b = createButton() b.onClick(this::close) b.paint() } } class WindowsDialog extends Dialog { Button createButton() { return new WindowsButton() } } class WebDialog extends Dialog { Button createButton() { return new HtmlButton() } } ``` **Abstract Factory.** A standalone interface declares several creation methods, one per product kind; each implementation returns a matched set. Variation rides on **composition/delegation**: the client is handed a factory object. ``` interface GuiFactory { Button createButton(); Checkbox createCheckbox(); Menu createMenu() } class WindowsFactory implements GuiFactory { /* Windows* for all three */ } class MacFactory implements GuiFactory { /* Mac* for all three */ } class Dialog { Dialog(GuiFactory f) { ... } } // no subclassing needed ``` ### The four axes of difference | Axis | Factory Method | Abstract Factory | |---|---|---| | Products covered | one kind | several kinds forming a family | | Variation mechanism | subclass the creator (inheritance) | inject a different factory object (composition) | | Who decides the variant | the choice of creator subclass, often made by the same code that owns the algorithm | the composition root that injects the factory | | Change at runtime | requires a different creator instance/subclass | swap the factory reference; can even be reassigned | ### Why the distinction matters practically 1. **Inheritance is a stronger coupling.** With Factory Method you cannot vary the product independently of the creator's other behavior — the variant and the algorithm are baked into one class hierarchy. If you need Windows-vs-Mac *and* modal-vs-modeless, inheritance multiplies (`WindowsModalDialog`, `MacModelessDialog`, …). Abstract Factory keeps those axes orthogonal: one `Dialog` class, injected factory for the platform axis. 2. **Consistency.** Factory Method makes no promise that two separately overridden factory methods produce compatible products. Abstract Factory does, because one object answers all of them. 3. **Testability.** Abstract Factory is trivially faked — pass a stub factory. Factory Method requires creating a test subclass, which is heavier and impossible on sealed/final creators. ### They compose The canonical GoF text notes that Abstract Factory implementations are "usually implemented with factory methods": each `createX()` inside `WindowsFactory` *is* a factory method in the loose sense. Some implementations use Prototype instead — the concrete factory holds prototype instances and clones them, which lets one factory class serve many variants configured at runtime. ### Common confusions to clear up - **"Simple Factory" / "Static Factory" is neither.** A static method or a class with a `switch` on a type string is a coding idiom, not a GoF pattern; it is neither Factory Method (no subclass override point) nor Abstract Factory (no family). - **A single-method interface with implementations is *not* automatically Abstract Factory.** With only one product kind, you have an injected factory (a strategy for creation). The family is what makes it Abstract Factory. - **Static factory methods on the product class** (`Duration.ofSeconds(…)`) are named constructors, unrelated to either pattern. ### Choosing between them Ask: *Does anything else vary with this product?* If exactly one thing is created and the creating class naturally has subclasses that already differ in behavior, Factory Method is lighter. If two or more product kinds must be from the same variant, or the variant must be selectable from outside without subclassing, choose Abstract Factory. If the variant count is one and unlikely to grow, choose neither and construct directly — or let a dependency-injection container do the wiring.
- Can Abstract Factory and Factory Method appear in the same design?Yes, and they usually do: each creation method of a concrete factory is itself a factory method, and factories are sometimes implemented via Prototype (cloning stored instances) instead.
- You have one product kind but need to choose its implementation from configuration without subclassing anything. Which pattern is that?Neither, strictly. It is an injected creation strategy — a one-method factory interface. Calling it Abstract Factory overstates it because there is no family; calling it Factory Method is wrong because there is no creator subclass.
Factory Method is a recipe that says "the bread step is up to the regional cookbook" — you change results by picking a different cookbook edition. Abstract Factory is a supplier contract: you sign with the Italian supplier and everything delivered — flour, cheese, oil — arrives matched.
saying these in an interview costs you the question
- Saying "Abstract Factory is a factory of factories" — that is a slogan, not the distinction; the real difference is a family of products plus composition instead of inheritance.
- Treating a static `create(type)` method with a switch as Abstract Factory.
- Claiming the two patterns are alternatives that cannot coexist.
- Describing Factory Method as requiring a separate creator interface injected into the client — that is the composition mechanism of Abstract Factory.