Resolution:
Open closed principle: open to extension, closed to modification. Static factory increase need is to modify the source code, the modification is not closed, does not conform to the open and closed principle.
Simple Factory Mode (static Factory)
1) Simple Factory mode belongs to the creation mode,
2) Simple Factory mode is made up of one factory (note one!). Object decides which product class to create (for example, if you go to KFC and say you want chicken legs, fries, drink, or something else, KFC is a factory and the client just needs to specify what it wants)
3) The essence of the implementation: a factory class dynamically decides which instances of product classes (which inherit from a parent class or interface) should be created based on the parameters passed in.
The UML class diagram is as follows:
Analysis:
Factory role: directly called by the client, according to the parameters specified by the client, dynamically create objects needed by the client;
Abstract product roles: Parent classes (interfaces) for all objects;
Concrete product roles: That is, the creation target of the factory, and the objects created by the factory are objects of these concrete classes.
It can be seen that the client only faces the factory, regardless of the specific details of the product, the customer only needs to ask the factory what you need, other things are left to the factory.
Advantages: By using the factory class, the outside world is freed from the embarrassment of directly creating concrete product objects and is simply responsible for “consuming” them. Regardless of how the objects are created and organized. Their responsibilities and rights have been clarified. (To put it simply, you can go to KFC and say whether you want chicken legs or wings, regardless of how the legs and wings are made, the factory provides you with such an interface).
Disadvantages: Because the factory class centralizes the creation logic of all instances, it violates the principle of highly cohesive responsibility allocation and centralizes all creation logic in one factory class. The classes it can create can only be considered in advance, and if new classes need to be added, the factory class needs to be changed.
As the number of specific product classes in the system increases, there may be a requirement for the factory class to create different instances based on different conditions. This kind of judgment to the condition and the judgment to the specific product type are interlaced together, it is difficult to avoid the spread of module function, which is very unfavorable to the maintenance and expansion of the system;
Usage scenarios
The factory class is responsible for creating fewer objects;
The customer only knows the parameters passed into the factory class and doesn’t care how the object is created (logically);
Because simple factories are easy to violate the principle of highly cohesive responsibility allocation, they are generally only used in very simple cases.
As you can see from the above example, factory classes often use reflection to generate concrete objects. (because different classes inherit from the same interface), extensibility is limited, and the product category has to be known in advance, so when you want to add a concrete class that isn’t part of a public interface, you can’t.
In addition, if you don’t use reflection or a common interface and use other logic in the factory (such as judging incoming strings) to create objects based on user parameters, then scalability is poor and logic and additions will only multiply.
Factory method pattern
The UML class diagram is as follows:
This is different from the simple factory pattern, which has only one factory, and the factory method pattern, which has a factory for each product.
Benefits: To add an operation class (such as N power class), only need to add the operation class and the corresponding factory, two classes, no need to modify the factory class.
Disadvantages: adding operation classes will modify the client code, the factory method simply moves the internal logic of the simple factory to the client.
Abstract Factory Abstract Factory
The UML class diagram is as follows:
participants
AbstractFactory — Declare an interface ConcreteFactory for a class of product objects AbstractProduct — implement an operation ConcreteFactory for a class of product objects Define a product object that will be created by the corresponding concrete factory ② implementing the AbstractProduct interface
Client ① uses only interfaces declared by AbstractFactory and AbstractProduct classes
collaboration
① An instance of the ConcreteFactory class is usually created at runtime. This concrete factory creates a product object with a specific implementation. To create different product objects, customers should apply different specific factories.
②AbstractFactory delays the creation of a product object to its ConcreteFactory subclass.
Factory method pattern: ① An abstract product class can be derived from multiple concrete product classes. ② An abstract factory class can be derived from multiple concrete factory classes. ③ Each concrete factory class can create only one instance of a concrete product class.
Abstract factory pattern: ① Multiple abstract product classes, each abstract product class can be derived from multiple concrete product classes. ② An abstract factory class can be derived from multiple concrete factory classes. ③ Each concrete factory class can create multiple instances of concrete product classes.
Differences: ① The factory method pattern has only one abstract product class, while the abstract factory pattern has multiple. ② The concrete factory class of the factory method pattern can create only one instance of the concrete product class, whereas the abstract factory pattern can create multiple instances.