You have an established Abstract Factory interface with several concrete factories in production. What happens when you need to add a brand-new product kind to the family, and how would you mitigate the cost?

### The grid, and why extensibility is asymmetric An Abstract Factory design is a two-dimensional grid: ``` createButton createCheckbox createMenu DarkFactory Dark… Dark… Dark… LightFactory Light… Light… Light… HighContrast… HC… HC… HC… ``` - **Adding a row (a new variant)** = one new class implementing an existing interface. Nothing else compiles differently. This is the pattern's selling point and a textbook illustration of the **Open/Closed Principle** (open for extension, closed for modification). - **Adding a column (a new product kind)** = a new method on the interface, so *every row* must gain a cell. If there are 3 variants that is annoying; if the interface is published to plugin authors, it is a **breaking change** — their code no longer compiles against the new version. This asymmetry is intrinsic, not a flaw in a particular implementation. Any design that enumerates operations in an interface is cheap to extend with implementations and expensive to extend with operations — the same trade-off as the Visitor pattern (easy to add operations, hard to add node types; Abstract Factory is the mirror image). ### Mitigation 1 — challenge the family boundary The cheapest fix is often to notice the new kind is not actually part of the family. Signs: only one or two variants can meaningfully produce it; nothing in the client needs it to match the other products' variant. Then it belongs in its own factory or plain construction, and the existing interface stays untouched. ### Mitigation 2 — default methods / optional operations Many languages allow interface methods with bodies (default methods, abstract classes with a base implementation, mixins). Adding `createSlider()` with a default that throws `UnsupportedOperationException` or returns an absent/no-op value keeps every existing implementation compiling. Trade-off: you have moved a compile-time error to runtime. The type system no longer tells you which variants are complete; clients must handle the unsupported case (feature check, capability query, or catching the exception — the first two are far better). This is exactly the tension the **Interface Segregation Principle** warns about: "clients should not be forced to depend on methods they do not use", and its cousin, don't force implementers to stub out operations they cannot honor. In inheritance terms, a factory that throws on half its methods is a **Liskov Substitution Principle** smell: it is not truly substitutable for the interface it claims. ### Mitigation 3 — split the interface If product kinds cluster (`ControlsFactory` for button/checkbox/slider, `ChromeFactory` for menu/toolbar/statusbar), split them. A concrete variant class can implement both, or several classes can be composed. Adding a kind now touches only implementers of the smaller interface. Cost: clients that need both must be given both (or a composite), and the *single* consistency guarantee weakens — two independently injected factories can be from different variants unless you keep a bundling type that hands out both. ### Mitigation 4 — generic / registry-based creation Replace the enumerated methods with a lookup: ``` interface ProductFactory { <T> T create(ProductKind<T> kind) // or: Optional<T> create(Class<T>) } ``` or a registry mapping kind → creator function that variants populate at construction. - Adding a kind: no interface change at all. - Cost: the compiler can no longer verify a variant is complete; return types need generics gymnastics or casts; discoverability drops (you can no longer read the interface to learn what the family contains); refactoring tools lose track of usages. It also invites a service-locator style where dependencies become invisible. Use it when kinds are genuinely open-ended and supplied by plugins; avoid it when the family is a small fixed set. ### Versioning strategies for a published interface If the abstract factory is a public extension point, the usual library tactics apply: introduce `GuiFactoryV2 extends GuiFactory` with the new method and have the framework check `instanceof`/capability at runtime; or ship an abstract base class that implementers are told to extend, so new methods can be added with defaults without breaking anyone. Both trade purity for compatibility. ### The decision, summarized Ask two questions. *Is the interface internal?* If yes, just add the method and fix all implementations in the same commit — the compiler will list them, and this is the safest outcome. *Is the new kind universal across variants?* If no, do not put it in the shared interface at all. Only when the interface is public **and** the kind is universal do you need defaults, versioned sub-interfaces, or a registry.