A brief talk on the model of design from simple to complex evolution of factory class

Objective

In the software design process, we always need to create many objects, and the larger the system, the more complex the objects are created. And today we're going to talk about solving the problem of object creation-the factory class pattern. To get close to the word factory, we use the example of factory-built cars to illustrate the evolution of factory-class patterns and what patterns to use in what scenarios.

Scenario 1: A customer wants to drive from Shanghai to Suzhou and he needs a car, so he assembles his car, tires, navigator, headlights, etc.

Question: 1, obviously, the customer just want to own a car, he does not want to know how to buy a car, but do not want to know how to assemble, and then also to paint the car.

2, if he wants to change a model of the car, he has to re-assemble the car.

The code can be expressed as:

First we need a car class

　　

Then the client was involved in making the car.

　　

If this is really the case, it is estimated that the customer will vomit blood, he just want to have a car to Suzhou, his own car is too sick, so he flatly will not. If he wants a car of another model, he needs to change the whole code.

　　

　　This violates the two principles of the design pattern: the Dimitri rule and the open and closed principle. The client only needs a car, adhering to the principle of minimum knowledge, customers only need to get a spray paint, air-conditioned car. At the same time, the modification can not be closed, if the customer wants to change a model of the car, he needs to modify a large number of code.

　　

　　The reality of this scenario is certainly not there, and the reality is that customers will get a car from a factory (company).

　　

Scene 2, top the customer was smart enough to buy a car from a factory that produced a BMW car.

Solve the problem: shielding the specific construction details of the car, customers no longer need to learn painting, install the engine.

The code is represented as follows:

Car class is still the same, just add a factory class, what the previous client did to install the engine code for the factory to complete.

　　

The client code calls the factory class directly, gets the car, and starts the trip.

　　

　　

From the above code can be clearly seen, the client to the concrete details of the object construction, such as painting, installation of the engine is not known, just got the car, and can drive her. This has satisfied its needs. And if you want to change a car, the client code doesn't need any modification.

In this scenario, the design pattern used is simple Factory mode.

Intent: Masking the specifics of client object instantiation; Provides an interface for creating objects.

Scene 3, suddenly one day, the customer earned 100 million, he told the director he needs to buy a lot of cars, may be Mercedes-Benz, or BMW, may also be Ferrari.

facing problems: 1 , how to ensure the normal operation of the original production line under the premise of the production of Mercedes-Benz and Ferrari.

Solution: 1, the director would like to, if the 3 kinds of cars are placed in a production line, it is certainly not good, in case the new changes affect the production of the former BMW line, it is finished (we write code, is not often simple to modify the original code, but is risking the original function of the risk? )。 So he added 2 new factories to produce Mercedes Benz and Ferrari respectively. Furthermore, if new models are to be produced in the future, there will be a direct addition of a factory, as long as the "abstract Factory" and the customer's agreement can be followed, without fear of affecting the production of the original car.

The face of the problem: 2, now has 3 factories, there are 3 director, if customers want to buy BMW, it is necessary to find a BMW factory director, buy Mercedes-Benz will find the factory director. The customer is not willing to, maybe not to buy.

Solution: Provide an "abstract factory director", he only negotiated with the customer, the specific car construction, by the specific director to be responsible.

Expressed in code as:

Defines a car's interface icar, which defines the services that a car can provide, including painting, air conditioning, driving, etc.

　　

The car class above slightly changed, is to implement the Icar interface.

The client code is:

　　

And then define an "abstract factory director", responsible for and customers agreed to purchase agreement.

　　

Define two factories to produce Mercedes-Benz and BMW, they follow the "abstract factory manager" and the customer's agreement is to build a car.

　　

　　

The client classes are as follows:

　　

Now you can see that the customer code has become very concise, and the factory can quickly new factories to produce cars without affecting the original car production, which is very good in the rapid change of the automotive industry, and provide customers with more and more concise service, such enterprises, natural competitiveness is strong.

The design pattern used here is the factory method pattern:

Intent: Define an interface for creating objects, so that subclasses decide which class to instantiate, and the factory method defers the instantiation of a class to its subclasses.

Usage Scenario: 1, when the client program does not need to know the creation process to use the object.

2. When a class does not know the class of the object it must create.

3, when a class wants its subclass to specify the object it creates.

4, the client program used by the object of the possibility of change, or simply do not know which specific object to use.

Scene 4, with the rapid development of the automobile industry, competition is more and more fierce, in order to survive in the competition, the director decided to install a smart navigation system for each model of the car, but BMW can only install BMW navigation, Mercedes-Benz can only install Mercedes-Benz own navigation.

Solution: The director decided to put the production of the Navigator in each automobile factory.

The specific classes are as follows:

Added an interface and implementation class for a navigation instrument

　　

　　

Add an abstract factory and implementation class

　　

The client class is

　　

The design pattern used here is Abstract Factory mode:

Intent: Provides an interface for creating a set of related or interdependent objects without specifying their specific class.

Usage Scenario: 1. Abstract Factory mode can be used when the object to be created is a series of interrelated or interdependent product families.

2. When a system is to be configured by one of multiple product families.

3. When you want to emphasize the design of a series of related product objects for joint use.

Scene 5, as the assembly of the car becomes more and more complex, the factory is unable to adapt to the rapid change of the outside world, so the director decided that the factory is just the parts needed for the production of automobiles, which is assembled by a specialized factory. Usually the car parts are relatively fixed, but the assembly process is more variable, the volatile separation, the constant retention, so as to better deal with the external changes. In addition, different parts can be used to build all kinds of automobiles.

The code is:

Compared to the abstract factory, we only added a Director class, responsible for the complex logic of car manufacturing.

　　

The client only needs to communicate with the Director class.

　　

The pattern used here is Builder mode.

Intent: To separate the construction of a complex object from its representation so that the same build process can create different representations.

　　

Summarize

Several of the models described above are adhering to the "to pull the variable parts out and use abstractions instead of concrete implementations", because the concrete is variable and the abstraction is constant. So we are in the process of code design, how to abstract, how to change easily into the same is very important. At the same time, remember that the "least known principle", if the client knows more, that code more constraints, the ability to face change is weaker.

Reference documents

23 different design modes

Factory Method Design Pattern

Factory Method Pattern

design mode (i) Factory mode factory (creation type)

Design mode-the basis of reusable object-oriented software

　　

A brief talk on the model of design from simple to complex evolution of factory class