The cornerstone of design patterns-Simple Factory

A simple factory is actually called a separate design model, because it is too simple. It is the simplest and most direct in OO, an application or the original intention.

What is Factory )? Factory is the place where the class Instance is constructed. Why should I create a class instance in another place? Bus aBus = new Bus (); is there anything wrong with this line of code? Yes, the benefits of OO can be used only when the instance of the class is created and used separately. Otherwise, polymorphism cannot be implemented. If the encapsulation defines the granularity of objects and inheritance ensures the reuse of data and behavior, polymorphism can respond to various changes on the basis of abstraction. Isn't the design pattern a general approach (pattern) to solve changes and reuse? Therefore, if you want to implement certain scalability on the Bus and reuse its data and behavior as much as possible, this line of code will not work.

How is the factory implemented?

From Bus aBus = new Bus (); we can abstract the first step. Bus belongs to Vehicle. Can I define a Vehicle class so that the Bus class can inherit from the Vehicle class? In the future, Vehicle data and behavior can be reused for other Vehicle-related classes. After modification, this line of code can be written as follows:

Vehicle aBus = new Bus ();

Looking at this change, it means the beginning of abstraction, the beginning of reuse, and the beginning of coping with changes.

This is not enough. Can we separate the creation and use of Vehicle? Of course:

Vehicle aBus = VehicleFactory. CreateBus ();

Why do we need to separate object creation and use? By the way, separation can cope with changes. For example, if you need to add a vehicle type such as Train on a certain day, and the logic is the same as that of the Bus, you only need to add the implementation of Train in the created place, without modifying the code used. However, the current VehicleFactory. CreateBus () still has a name coupling with the Bus and uses the method for creating the Bus. Let's change it:

VehicleFactory. Create ("bus"); how about this? If you want to completely decouple, it will be like this:

VehicleFactory. Create (ConfigurationManaer. deleetask[ "vehicleType"]. ToString ());

This is a changing direction, that is, extending from Bus to Train. What if there is a need to modify the Bus itself? For example, if the previously implemented Bus is based on Jinlong passenger car, now we need to use an Kai passenger car. The key is that there are different places between an Kai passenger car and a Jinlong passenger car. At this time, there are two ideas: one is to extract a layer between Bus and Vehicle, which is used to represent the abstract of Bus, and then give Jin long and an Kai their respective implementations. If the product has been launched, this change may be made elsewhere. Another option is to re-implement a Bus class to replace the previous Bus class, in the VehicleFactory. create () to Create a new Bus class. Because the creation and use of Bus are separated, we can easily achieve this.

Therefore, it is necessary to create and separate objects. If they are not separated, they cannot do everything above.

Therefore, a simple factory can be summarized as one sentence: separating object creation and use. In addition, a simple factory is the cornerstone of almost all design patterns.