之前对设计模式了解的不是很多,现在以前端为切入点来学习设计模式,在学习的过程中会借鉴其他人的博客和代码,会在文章末尾标注来源出处
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() {