Lesson 7 | Factory Method: consequences |
Objective | Write class using Factory Method pattern. |
Factory Method Consequences
Factory Method Design Pattern Consequences
Write a class that uses the Factory Method pattern.
Factory Method patterns take the last step toward removing all knowledge of the details of the subclass from the client classes. Indeed, in the Java class library, the concrete subclasses are often hidden inside the sun packages and are deliberately left undocumented. Of course this is not always what you want in a subclass, but when it is, the Factory Method gives it to you.
The Factory Method pattern also makes programs dynamically extensible at runtime. New concrete subclasses can be added to the system without recompiling the existing code.
Factory Methods are also useful in programs that require parallel class hierarchies. A parallel class hierarchy is one in which every Product
object requires one or more additional objects. For example, imagine that every time a
Vehicle
is created, a Driver
object also has to be created, a BusDriver
for a bus, a CarDriver
for a car, and so on. A Factory Method can create the parallel objects at the same time it creates the
product, guaranteeing that there's exactly one driver for each vehicle.
One disadvantage of the Factory Method pattern is that it can expand the total number of classes in a system. Every concrete Product
class also requires a concrete Creator
class. The parameterized Factory Method avoids this downside.
Factory
In general, all subclasses in a class hierarchy inherit the methods implemented by the parent class. A subclass may override the parent class implementation to offer a different type of functionality for the same method.
When an application object is aware of the exact functionality it needs, it can directly instantiate the class from the class hierarchy that offers the required functionality. At times, an application object may only know that it needs to access a class from within the class hierarchy, but does not know exactly which class from among the set of subclasses of the parent class is to be selected. The choice of an appropriate class may depend on factors such as:
- The state of the running application
- Application configuration settings
- Expansion of requirements or enhancements
In such cases, an application object needs to implement the class selection criteria to instantiate an appropriate class from the hierarchy to access its services
This type of design has the following disadvantages:
- Because every application object that intends to use the services offered by the class hierarchy needs to implement the class selection criteria, it results in a high degree of coupling between an application object and the service provider class hierarchy.
- Whenever the class selection criteria change, every application object that uses the class hierarchy must undergo a corresponding change.
- Because class selection criteria needs to take all the factors that could affect the selection process into account, the implementation of an applicationobject could contain inelegant conditional statements.
Factory Consequences - Exercise
Microservices Patterns