Extending Factories in Java

Extending a factory: Adding new creation options without forcing invasive changes across existing clients and creation code.

Factories are often introduced in the name of extensibility, but the real test comes later. Can a new product type be added without changing half the system? Can product-specific configuration stay local? Can callers remain stable?

Two Main Extension Styles

In Java, extension usually happens in one of two ways:

• subclassing an existing creator and overriding the creation hook
• registering or injecting a new creation strategy into a compositional factory

Subclassing fits when the creator already owns a meaningful workflow. Strategy or registry approaches fit better when extension should stay pluggable.

Prefer Stable Client Contracts

Clients should depend on the product contract, not on the extension mechanism itself. A caller ideally does not care whether a product came from:

• an overridden factory method
• a registry lookup
• a lambda-based supplier
• a DI-managed bean factory

If extension leaks into the caller, the factory is not buying much isolation.

Open/Closed Is A Useful Pressure Test

The Open/Closed Principle is not about never changing code. It is about putting the likely change point in the right place. For factories, that means the creation mechanism should make typical new variants cheap while keeping existing callers stable.

A practical smell is when every new product requires:

• new branching in several places
• edits to unrelated tests
• changes to base classes that were supposed to be stable

That means the extension seam is probably wrong.

Design Review Questions

When reviewing factory extensibility, ask:

• What changes when a new product is introduced?
• Is the extension seam based on inheritance or registration, and why?
• Are callers isolated from concrete product details?
• Is the creation mechanism still smaller than the variability it manages?

Good extensibility feels local. Bad extensibility advertises flexibility while distributing change cost across the codebase.