Javascript Design Mode-Factory Mode

I understand that factory mode is a mode that provides a unified entry for multiple related classes, so that you can get multiple classes from one entry and improve your productivity.

However, there are also three types of implementations for factory mode: simple factory mode, factory method mode and abstract factory mode. They are improved on their respective basis.

Simple Factory Mode

Also known as Simple Factory Patter, it is used to create objects of the same class.

Where applicable: If asked to write some implementation of a sphere class, we will do so in general:

var Football = function(){
    this.name = "football";
    ....
}
var Basketball = function(){
    this.name = "basketball";
    ....
}

There are some drawbacks in this way of writing: multiple classes have been returned, which is not easy for others to use. So we consider encapsulating these similar classes in a factory, and we have our simple factory model:

var BallFactory;
!(function(){
    BallFactory = function(type,cfg){
        var Football = function(cfg){
            this.name = 'football';
            console.log(this.name + " in the prototype");
        };
        Football.prototype = {
            call:function(){console.log(this.name)},
            sell:function(){}
        };
        var Basketball = function(cfg) {
            this.name = "basketball";
            console.log(this.name);
        };

        var cfg = cfg ||{};
        switch(type){
            case 'football':
                return new Football(cfg);
                break;
            case 'basketball':
                return new Basketball(cfg);
                break;
        }
    };
})();

var aFootball = BallFactory('football');
aFootball.call();

So using BallFactory to wrap these up for others avoids the problem of returning multiple classes, so that's what the simple factory model is trying to solve:
Unified entrance.

Of course, there are some other techniques we use in the actual use:

If there are many duplicate parts in the factory products, we need to abstract the duplicate parts into a common part and put different parts into the switch:

var GetChildren = function(cfg){
    cfg = cfg||{};
    this.name = cfg.name;
    this.height = cfg.height;
    this.speak = function(){};
    
    //Pull out different parts
    switch(cfg.gender){
        case "boy":
            this.gender = cfg.gender;
            this.moustouch = ....
            .....; //Unique parts
            break; 
        case "girl":
            this.gender = cfg.gender;
            .......
            break;
    }
    return this;
}
var aBoy = GetChildren({.....}); 

Factory Method Mode

On the basis of the simple factory model, we have solved the problem of inconsistent entrance, but there is still one problem that remains unsolved:

Joining a new class requires modifying many parts: first we need to add how to do this inside the BallFactory factory, then we need to add the switch part; so this is a requirement for one change, and we need to modify many places.

Then let's see if we can try to be more abstract and minimize the need to modify it.

var BallFactory = function(type,cfg){
    this.name = cfg.name; //Common parts put here
    return this[type](cfg);
};

BallFactory.prototype = {
    football:function(cfg){
        console.log("Add and here football Related Unique Content" +this.name);
    },
    basketball:function(cfg) {
        console.log("Add and here basketball Related Unique Content" +this.name);
    }
};
var aBall = new BallFactory("football",{name:"football"}); //football in the prototype

So here's a return this[type](cfg) method that automatically replaces the previous switch method. All you need to do in the future is modify the prototype of BallFactory.

Of course, we can also add a security pattern to solve the problem that would otherwise fail if we did not precede the constructor with new. The idea is to encapsulate new within the constructor:

var BallFactory = function(type,cfg){
    if(!(this instanceof BallFactory)){
        return new BallFactory(type,cfg); //One more line of judgment is that if you don't have a new one, I'll help you get one back.
    }
    this.name = cfg.name;
    return this[type](cfg);
};

var aBall = BallFactory("football",{name:"football"}); //If you drop new here, it will work as well;

So what we can see is that we used the simple factory model to solve the problem of inconsistent entry points, and then the factory model to solve the problem of inconsistent modification locations

Abstract Factory Mode

Generally speaking, Abstract factories are used more in large projects. The general idea is to design interfaces (not implemented) in the parent class and wait until the subclass is overridden.

Here's an example of an inscribed <JavaScript Design Patterns>

var Car = function(){};
Car.prototype = {
    getPrice:function(){ throw new Error("Abstract methods cannot be called")},
    getSpeed:function(){ throw new Error("Abstract methods cannot be called")}
};
//Using Object.create() inheritance here, there will be one more intermediate transition function Temp(){} from the child class to the parent class; prevent overwriting the parent class with the prototype of the child class;
aBMW = Object.create(Car.prototype);
    
aBMW.getPrice();  // Abstract methods cannot be called
aBMW.getPrice = function(){
    console.log("I am getting price");
};
aBMW.getPrice(); //I am getting price

The parent class defines the interface, and the implementation is delayed until the child class implements it.

So in summary:

The simple factory mode solves the problem of inconsistent entries.

The factory model solves the problem of changing locations that are not uniform.

The abstract factory pattern solves the problem of nonstandard subclass implementations.

At present, our newly revamped mobile form block logic is separated from rendering, which is similar to pulling a form page into a factory with over twenty different controls, each of which inherits the form class.