Design patterns are often asked in the interview. Since I wrote the single case pattern asked in detail yesterday, I might as well learn a design pattern every day. The overall feeling is that design patterns are very abstract and need to think about some problems, especially in daily code and work.

I checked many blogs and found that everyone spoke well about the representativeness of factory mode. For example, both factory mode and singleton mode belong to creative pattern, and then give different examples for everyone to understand. There's no teaching here. This article is a bit like translation. It may be more "academic" to analyze the factory model. This blog is based on Design Patterns and best practice in Java.

1, Origin of factory model

In object-oriented languages, there will be the feature of "polymorphism", or subtype polymorphism, which has the relationship of "is/a". For example, both cars and trucks can be used as vehicles. This feature makes our code look more concise and extensible. For example, we can easily implement bicycles and trucks without modifying the original code. Using polymorphism, we can use Vehicle to new Car or Truck and others.

Vehicle car = new Car();
Vehicle truck = new Truck();

However, the implementation of polymorphism will bring two problems. The first is code coupling, which is the coupling of parent and child classes. The other is that it is difficult to expand without modifying the code. For example, in the second line, I want a Truck and I need a new Truck. We need to abide by the opening and closing principle (open to extension and close to modification). Every time we add a main class to a Vehicle, we violate this principle. As the main class, Vehicle needs to instantiate subclasses, which violates the principle of single responsibility (each class has only one reason to change).

For the above reasons, we have introduced a new design - we add a new class to instantiate Vehicle. This leads to the simple factory mode.

2, Simple factory mode

In fact, this translation can be replaced by a concise factory model. Explanation of the above reasons: the factory mode mainly summarizes the logic of instantiating objects through a common interface, so as to minimize code changes when adding new classes. The simple factory mode is shown in the figure below:

SimpleFactory implements createProduct to implement ConcreteProduct1 and ConcreteProduct2. When a client needs an object, it can call the createProduct method and specify the required object through the parameters of the method. SimpleFactory instantiates and returns the object to the Product for distribution. The code is as follows:

This minimalist, simple static factory satisfies the principle of single responsibility and inversion of dependency. However, when adding a "Product", the main class VehicleFactory needs to be changed, so it still violates the opening and closing principle. We can improve it in two ways: 1. Register the Product class and instance it (using reflection) 2. Register the Product object and add a new instance to each object to return the original instance. This explanation is somewhat abstract and even awkward. The code:

Use map to record different objects

private Map<String, class> registeredProducts = new HashMap<String, class>();

Then register a vehicle

public void registerVehicle(String vehicleId, Class vehicleClass){
    registeredProducts.put(vehicleId, vehicleClass);
}

Change the create method

public Vehicle createVehicle(String type) throws InstantiationException, IllegalAccessException{
    Class productClass = registeredProducts(type);
    return (Vehicle)productClass.newInstance();
}

Reflection may not be very good in some cases: 1. Reflection requires the permission of runtime, but sometimes it can't. 2. Reflection will sacrifice performance. So the alternative: add an instance to each object we want to register.

Add an abstract method in VehicleFactory

abstract public Vehicle newInstance();

In this way, every product should implement this method

@override
public Car newInstance(){
    return new Car();
}

Register product map

private Map<String, Vehicle> registeredProducts = new HashMap<String, Vehicle>();

Register a new Vehicle by passing an instance

public void registerVehicle(String vehicleId, Vehicle vehicle){
    registeredProducts.put(vehicleId, vehicle);
}

Then we change the createVehicle method

public AbstractProduct createVehicle(String vehicleId){
    return registeredProducts.get(vehicleId).newInstance();
} 

3, Factory method model

The improvement of static methods is still lengthy, even including reflection. Therefore, the factory method pattern is used to improve. The factory method pattern uses both abstract classes and interface implementations. Above:

The factory class is abstracted and instantiated to the following inherited subclasses. In this way, the factory can be extended without changes. Suppose we have an automobile factory to produce small sports cars and family cars. In our software, customers can choose any one, such as sports cars or SUV s. We can start with classification, divided into sports cars and family cars. We first write an abstract class: vehicle factory:

public abstract class vehicleFactory{
    //abstract method that subclasses can implement
    protect abstract Vehicle createVehicle(String item);
    
    public Vehicle orderVehicle(String size, String colour){
        Vehicle vehicle = createVehicle(size);
        vehicle.testVehicle();
        vehicle.setColour(colour);
        return vehicle;
    }
}

In order to build an example of a car, we can first establish my car factory

public class CarFactory extends VehicleFactory{
    @override
    protected Vehicle createVehicle(String size){
        if(size == "small"){
            return new SportsCar();
        }else if(size == "large"){
            return new SedanCar();
        }
        return null;
    }
}

As a client, we can achieve this:

VehicleFactory carFactory = new CarFactory();
carFactory.orderVehicle("large","blue");

At this time, through market research, we find that trucks are more popular, so we can build our truck factory. As a client, we don't need to know what the truck factory is. How to make trucks only needs to care about the two parameters of orderVehicle.

4, Anonymous entity factory

If we think bicycles are better at this time, we can build our bicycle factory. We can even use anonymous internal classes without creating additional classes:

VehicleFactory bikeFactory = new VehicleFactory(){
    @override
    protected Vehicle createVehicle(String size){
        if(size == "small"){
            return new MountainBike();
        }else if(size == "large"){
            return new CityBike();
        }
        return null;
    }
};
bikeFactory.orderVehicle("large","blue");

5, Abstract factory

Abstract factory is an extension of factory method. Unlike factory methods that create only one object, abstract factory methods create a family of related objects. If the factory method has an abstract product, the abstract factory creates columns of abstract products. In fact, the factory method is like a special one in the abstract factory. Abstract factory diagram:

AbstractFactory: abstract factory class, which declares all product types, as shown in figures createProductA and createProductB.

ConcreteFactory: inherits the abstract factory class and implements the create method of the abstract factory class. This class is responsible for the factories of various entity classes.

AbstractProduct: abstract product class, basic interface or class. For the final product, ProductA1 and ProductB1 in the figure belong to one family (concretefactory1), and producta2 and ProductB2 belong to one family (ConcreteFactory2).

6, Summary

In summary, there are three ways to implement the factory pattern: simple factory, factory method, and abstract factory. They are not easy to distinguish because there is a lot of overlap. Core concept: the factory pattern is to delegate the responsibility of the appropriate object to the appropriate factory class. If our factory is very complex and serves many types, such as bicycles and motor vehicles mentioned earlier, we can still change our code according to the reason, so as not to be very chaotic.