The difference between several factory models

Simple Factory mode, factory method mode and abstract Factory mode are all created design patterns, and none of the three creation models need to know the specific class. We grasp the idea that when creating an object, it is necessary to encapsulate the changes that are prone to change (where changes are made, where they are packaged) to accommodate the changes in the customer and the expansion of the project. With these three kinds of design patterns can be achieved, then what are the three design patterns have what similarities and differences? The following are based on the characteristics of these three, advantages, disadvantages, the scope for comparison.

Characteristics

Simple Factory mode: specifically defines a class to be responsible for creating instances of other classes, and the instances that are created typically have a common parent class. It is also called the Static factory method mode. The essence of this is that a factory class dynamically determines which product class (these product classes inherit from a parent class or interface) should be created, based on the parameters passed in. The simple factory model is created to target all created objects as instances of a specific class that serves this role. In this mode, the factory class is the key to the entire pattern. It contains the necessary judgment logic to determine which specific class of objects should be created based on the information given by the outside world. Users can create the required instances directly from the factory class, without having to know how they are created and how they are organized. facilitates the optimization of the entire software architecture.

Factory method Mode: The factory method is a small-grained design pattern, because the pattern's performance is only an abstract approach. Define the interface used to create the object in advance, so that subclasses decide to instantiate a particular class, that is, to add an interface between the factory and the product, the factory is no longer responsible for the product creation, and the interface returns the concrete class instance for different conditions, which is implemented by the concrete class instance. The factory method model is a derivative of the simple factory model, which solves the problem of many simple factory models. First, the ' open-closed principle ' is fully realized and extensible. The second is to achieve more complex hierarchy, can be applied to product results in complex situations. The factory method pattern is an abstraction of the simple factory pattern. There is an abstract factory class (which can be abstract classes and interfaces), and this class will not be responsible for the production of specific products, but only to formulate some specifications, specific production work by its subclasses to complete. In this mode, the factory class and the product class can often correspond in turn. That is, an abstract factory corresponding to an abstract product, a specific factory corresponding to a specific product, this specific factory is responsible for the production of the corresponding products.

Abstract Factory mode: Abstract Factory mode is the most abstract and general form of the factory pattern of all forms. Abstract Factory mode refers to a factory pattern that is used when there are multiple abstract roles. Abstract Factory mode provides the client with an interface that enables the client to create product objects in multiple product families without having to specify the product's specific circumstances. It has a number of abstract product classes, each abstract product class can derive a number of specific product classes, an abstract factory class, you can derive a number of specific factory classes, each specific factory class can create more than one instance of a specific product class. Each model is a solution to a problem, and the factory approach model is for a product hierarchy, while the abstract factory model is for multiple product level results.

Advantages

Simple Factory mode: The factory class contains the necessary judgment logic to decide when to create an instance of the product class, and the client can dispense with the responsibility to create the product object directly, but only "consume" the product. The simple factory model achieves the separation of responsibilities through this approach. The simple factory model is able to determine which specific class of objects should be created based on the information given by the outside world. Through it, outsiders can get out of the awkward situation of directly creating specific product objects. The outside is isolated from the specific class, the coupling is low. Clearly distinguishes the respective responsibility and the power, facilitates the entire software system structure optimization.

Factory method Mode: The factory method pattern is designed to overcome the drawbacks of the Simple factory model (mainly to meet the OCP). Factory classes in simple Factory mode as the product class increases, many methods (or code) are added, while the factory method pattern accomplishes only a single task for each specific factory class, and the code is concise. The factory method model completely satisfies the OCP, i.e. it has very good extensibility.

Abstract Factory mode: The abstract factory model mainly lies in response to the "new series" of demand changes. Separating the specific classes, the abstract factory pattern helps you control the class of an application-created object, because a factory encapsulates the responsibility and process of creating product objects. It separates the implementation of the customer from the class, the client manipulates the instance through their abstract interface, and the class name of the product is also separated from the implementation of the specific factory, which is not present in the customer code. It makes it easy to exchange product lines. A specific factory class appears only once in an application-that is, when it is initialized. This makes it easy to change the specific factory of an application. It only needs to change the specific factory to use different product configurations, because an abstract factory creates a complete product line, so the entire product line changes immediately. It is conducive to product consistency. When a series of product objects are designed to work together, it is important that an application can only use objects from the same series at a time, which is easy for an abstract factory to achieve. Abstract factory model can help the division of the team, reduce the coupling between the modules, improve team development efficiency.

Disadvantages

Simple Factory mode: When the product has complex multilayer hierarchy structure, the factory class only own, Status quo, is the disadvantage of the pattern. Because the factory class centralizes all product creation logic, the entire system is affected once it does not work properly. System expansion is difficult, once adding a new product will have to modify the factory logic (if you want to add a product, you need to modify the factory class, add If/else Branch, or add a case branch), may cause the factory logic is too complex, contrary to the "open-closed" principle (OCP). In addition, Simple Factory mode typically uses a static factory approach, which makes it impossible to inherit from subclasses, resulting in a factory role that cannot form an inheritance-based hierarchy.

Factory method Mode: Not easy to maintain, if a specific product class needs to make certain changes, it is likely to need to modify the corresponding factory class. When you need to modify multiple product classes at the same time, the modification of the factory class becomes quite cumbersome (it is already a problem).

Abstract Factory mode: Abstract Factory mode is difficult to cope with the "new object" demand changes. It is difficult to support new kinds of products. It is difficult to expand the abstract factory to produce new kinds of products. This is because the abstract factory almost identifies a collection of products that can be created, and supporting the new kind of product requires extending the factory interface, which involves the transformation of the abstract factory class and all its subclasses.

Scope of application

Simple Factory mode: The factory class is responsible for creating fewer objects, and the customer knows only the parameters that passed into the factory class, and does not care about creating objects (logic).

Factory method Mode: When a class does not know that it must create an object's class or a class that expects subclasses to specify the object it creates, the factory method can be used when the class delegates the responsibility of creating an object to one of several helper subclasses, and you want to place a helper subclass that is a proxy for this information.

Abstract Factory mode: A system should not rely on the details of how a product class instance is created, composed, and expressed, which is important for all forms of Factory mode. This system has more than one product family, and the system only consumes one of the product families. Products belonging to the same product family are used together, and this constraint must be reflected in the design of the system. The system provides a library of product classes, with all products appearing on the same interface, so that clients do not rely on implementations.

In fact, whether it is a simple factory model, a factory model, or an abstract factory model, they essentially extract the invariant parts and leave the variable portions as interfaces for maximum reuse. Which design pattern is more appropriate, depends on the specific business needs.

Also, attach a metaphor for these kinds of factory models. Whether it is a simple factory model, a factory model, or an abstract factory model, they essentially extract the invariant parts and leave the variable portions as interfaces for maximum reuse. Take an example of a factory producing a water cup (CUP): At first, without a factory model, I had to know all the characteristics of the water cup, such as the material and shape of the cup, before producing it, which is our new cup (); This cup must be specific. Factory owners found the same shape of the quilt, but the material is different, such as a glass (glass), one is porcelain (China), but it is necessary to two production lines, obviously there is a suspicion of waste of resources. Now the factory main production Cup first not let the production line know that I want to produce is glass or porcelain, but let it do not know the specific material of the case first do it can do, wait until it does the mold well, just to fill the glass raw materials or porcelain raw materials can be made out of the same shape of the specific cup. Unfortunately, Java is not new to an abstract cup, so there is a simple factory pattern. It turns out to be the Cup Cup=new Cup; now it's Simplecupfactory.createcup (String cupname), which produces the cup based on the Cup name, and Createcup returns a specific cup that implements the Cup interface or abstract class. Simple abstract Factory Model There is a problem, that is, when I want to produce a similar shape of the Iron Cup, the factory does not define the corresponding process, can only change the Createcup method, which is unreasonable. I just want to make the Iron Cup, you just have to change the glass material to iron in the last time, why do you have to make the whole production line? So there is the factory model. The original production line in the manufacture of molds should also be considered for the production of glass molds or molds for the production of iron cups, now it does not tube. Cupfactory.createcup () Create Cup.cupfactory is an interface or abstract class. The specific subclass that implements it creates a specific cup that matches the CPU interface. So now the factory owners want to produce water bottle (kettle), with the factory model will have to recreate a kettle production line, can be in the glass production line at the same time to produce a kettle? This is the abstract factory pattern.

The difference between several factory models