The factory method never understood its value, though it knew its form. Today’s iOS Design Pattern Analysis + this answer suddenly came to light. Let me reinterpret it as I understand it.

First, set up the background

For a module, it provides services, and the specific content of services is unknown to the outside world. For example, the restaurant provides services for eating, and the outside world does not know how the specific dishes are made (because of the division of labor, it is impossible to know everything). The service is the interface, and the service is the implementation of the service.

Then, one interface may correspond to multiple services, which are also “ordering dishes”. Different dishes differ greatly, and different chefs and restaurants differ greatly from the same dish. So there are a number of differentiating factors that together determine what implementation the interface will choose.

So you can see that there is a logical judgment about the association from the interface to the implementation, and the factory method is that logical judgment, except that it’s a service that “creates an object.”

The factory method is a special case

Now I’m going to create an object, but I only have a few distinguishing factors, like building a car, I only know the color, the category, and so on, and based on the logic of how to create an object based on those factors, I’m going to write it in a unified method, which is the factory method.

The benefits of this are:

  1. Who knows better by this logic? Creator or caller? It must be the creator, who provides the service for creating objects.
  2. Using a unified method can ensure the unity of judgment logic, if you want to modify the logic in the future, only need to modify one can.

Imagine what you could do without the factory approach:

  1. I’m going to do a logic check on each of the places I build, and I’m going to write Nif-else“And then as the needs change, they have to change everywhere
  2. For each build, I know exactly which object to build, so I don’t have to make judgments and just specify which object to build. If the object belongs to another module, doing so would be equivalent to inserting the logic of the build selection into the current module. Even more obviously, that module is made by another part, and both departments have to change the code when the requirements change, which would be messy.

With the factory method, as long as the declaration of the method remains unchanged, the user does not modify the code, and the requirements change only when the module is created.

Just like building a car (building object), I want a red suv with a big space (distinguishing factor), I submit the requirements to the factory, and the factory gives me the car. As for how the factory builds the car, I don’t know what kind of car it makes and I don’t care, as long as my needs are met.

The core problem is not to focus on the object creation itself, but on the logic between external requirements and object selection, and the starting point of building a unified method to unify the flow of logic. The factory method is just a special case of the “interface +N implementation” model of “building objects”. Its core meaning is not “building objects” itself.

divergent

From this design point of view, I think it can be understood as a subset of the “interface oriented programming” philosophy. And the broader model is: one interface, N implementations, the outside world provides some differentiating factor, the interface is like the gate, the implementation is like the little door inside the gate, the differentiating factor flows through the gate, into different little doors. In addition to the factory model, there are many other places that do this.