Learn the vocabulary of centralizing object creation behind a method that decides which concrete class to instantiate.
0 / 5 completed
1 / 5
At standup, a dev mentions centralizing object creation behind a dedicated method that decides which concrete class to instantiate, so calling code never has to name a concrete class directly. What is this design pattern called?
The factory pattern is exactly this: the factory pattern centralizes object creation behind a dedicated method or class that decides which concrete class to instantiate based on input or configuration, so calling code depends only on an abstract interface and never has to name a concrete class directly. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This centralize-the-creation-decision approach is exactly why the factory pattern lets new concrete types be added without touching every place that creates objects.
2 / 5
During a design review, the team applies the factory pattern to a system that must support new object types over time, specifically because centralizing the creation decision in one place avoids scattering concrete-class references across every caller. Which capability does this provide?
The factory pattern here provides Decoupling of calling code from concrete classes, since callers depend only on an abstract interface, and adding a new concrete type only requires updating the factory method instead of every place that creates objects. Calling code that instantiates a concrete class directly wherever an object is needed must be updated at every one of those call sites whenever a new type is added. This centralized-creation-decision behavior is exactly why the factory pattern is favored in systems expected to support new object types over time.
3 / 5
In a code review, a dev notices a system that must support new object types over time instantiates a concrete class directly at every call site that needs an object, instead of centralizing that decision behind a factory method. What does this represent?
This is a missed factory-pattern opportunity, since centralizing the creation decision behind a factory method would let calling code depend on an abstract interface instead of every call site naming a concrete class directly. A cache eviction policy is an unrelated concept about discarded cache entries. This direct-instantiation-everywhere pattern is exactly the kind of scattered coupling a reviewer flags once new object types are expected to be added over time.
4 / 5
An incident report shows adding a new object type required touching dozens of call sites across the codebase, because each one instantiated a concrete class directly instead of going through a centralized factory method. What practice would prevent this?
Introducing the factory pattern centralizes the creation decision, so adding a new object type only requires updating the factory method. Continuing to instantiate a concrete class directly at every call site regardless of how many new object types the system is expected to support over time is exactly what caused the issue described in this incident. This factory-pattern approach is the standard fix once new object types are confirmed to be added regularly.
5 / 5
During a PR review, a teammate asks why the team reaches for the factory pattern instead of simply instantiating the needed concrete class directly wherever an object is required. What is the reasoning?
The factory pattern centralizes the creation decision behind one method, so adding a new concrete type only requires updating that one place, while direct instantiation is simpler for a fixed, small number of types but requires touching every call site whenever a new type is added. This is exactly why the factory pattern is favored in systems expected to grow their set of object types, while direct instantiation remains simpler for a small, stable set of types.