23.3. Factory (GoF)
The adapter raises a new problem in the design: In the prior Adapter pattern solution for external services with varying interfaces, who creates the adapters? And how to determine which class of adapter to create, such as TaxMasterAdapter or GoodAsGoldTaxProAdapter?
If some domain object creates them, the responsibilities of the domain object are going beyond pure application logic (such as sales total calculations) and into other concerns related to connectivity with external software components.
This point underscores another fundamental design principle (usually considered an architectural design principle): Design to maintain a separation of concerns. That is, modularize or separate distinct concerns into different areas, so that each has a cohesive purpose. For example, the domain layer of software objects emphasizes relatively pure application logic responsibilities, whereas a different group of objects is responsible for the concern of connectivity to external systems.
Therefore, choosing a domain object (such as a Register) to create the adapters does not support the goal of a separation of concerns, and lowers its cohesion.
UML notation— Observe the style in the UML diagram of Figure 23.4 that includes a note showing detailed pseudocode for the getTaxCalculatorAdapter. This style allows one to include dynamic algorithm details on a static class diagram such that it may lessen the need for interaction diagrams.
Figure 23.4. The Factory pattern.
A common alternative in this case is to apply the Factory (or Concrete Factory) pattern, in which a Pure Fabrication “factory” object is defined to create objects.
Factory objects have several advantages:
Separate the responsibility of complex creation into cohesive helper objects.
Hide potentially complex creation logic.
Allow introduction of performance-enhancing memory management strategies, such as object caching or recycling.
|
(Concrete) Factory Context/Problem Who should be responsible for creating objects when there are special considerations, such as complex creation logic, a desire to separate the creation responsibilities for better cohesion, and so forth? Solution Create a Pure Fabrication object called a Factory that handles the creation. |
A Factory solution is illustrated in Figure 23.4.
Note that in the ServicesFactory, the logic to decide which class to create is resolved by reading in the class name from an external source (for example, via a system property if Java is used) and then dynamically loading the class. This is an example of a partial data-driven design. This design achieves Protected Variations with respect to changes in the implementation class of the adapter. Without changing the source code in this factory class, we can create instances of new adapter classes by changing the property value and ensuring the new class is visible in the Java class path for loading.
Factories are often accessed with the Singleton pattern.
Related Patterns