Javascript设计模式：工厂模式

之前对设计模式了解的不是很多，现在以前端为切入点来学习设计模式，在学习的过程中会借鉴其他人的博客和代码，会在文章末尾标注来源出处

1. 简单工厂

根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

//汽车类
class Car {
   
    constructor({
    doors, state, color }) {
   
        //默认值
        this.doors = doors || 4;
        this.state = state || 'brand new';
        this.color = color || 'silver';
    }
}
// 卡车类
class Truck {
   
    constructor({
    state, wheelSize, color }) {
   
        this.state = state || 'used';
        this.wheelSize = wheelSize || 'large';
        this.color = color || 'blue';
    }
}
// 简单工厂
class VehicleFactory {
   
    constructor() {
   
        this.vehicleClass = Car;
    }
    // 工厂方法 创建一个车型实例
    createVehicle(options) {
   
        switch (options.vehicleType) {
   
            case 'car':
                this.vehicleClass = Car;
                break;
            case 'truck':
                this.vehicleClass = Truck;
                break;
            // VehicleFactory.prototype.vehicleClass (Car)
        }

        return new this.vehicleClass(options);
    }
}
const carFactory = new VehicleFactory();
const car = carFactory.createVehicle({
   
    vehicleType: 'car',
    color: 'yellow',
    doors: 6,
});

适用环境

在以下情况下可以使用简单工厂模式：

工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。

工厂模式的优点:

• 简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象
• 把所有实例化代码集中在一起，简化所用的类或在运行期间动态选择所用类的工作
• 弱化对象间的耦合 防止代码重复 在一个方法中进行类的实例化，可以消除重复代码，
• 用一个对接口的调用取代一个具体的实现,有助于创建模块化代码

工厂模式的缺点:

• 简单工厂模式最大的问题在于工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，这一点与开闭原则是相违背的。
• 由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
• 使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。
• 系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
• 简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

2. 抽象工厂

/**
 * 披萨原料工厂  接口
 * @class PizzaIngredientFactory
 */
class PizzaIngredientFactory {
   
    //该接口的方法必须覆盖重写，不允许子类继承调用
    createDough() {
   
        throw new Error("This method must be overwritten!");
    }

    createSauce() {