前端设计模式之【工厂模式】
文章目录
- 前言
- 什么时候不用
- 介绍
- 工厂模式的流程
- 例子
- 优点
- 缺陷
- 后言
前言
hello world欢迎来到前端的新世界
😜当前文章系列专栏：前端设计模式
🐱👓博主在前端领域还有很多知识和技术需要掌握，正在不断努力填补技术短板。(如果出现错误，感谢大家指出)🌹
💖感谢大家支持！您的观看就是作者创作的动力
什么时候不用
当被应用到错误的问题类型上时,这一模式会给应用程序引入大量不必要的复杂性.除非为创建对象提供一个接口是我们编写的库或者框架的一个设计上目标,否则我会建议使用明确的构造器,以避免不必要的开销。
由于对象的创建过程被高效的抽象在一个接口后面的事实,这也会给依赖于这个过程可能会有多复杂的单元测试带来问题。
介绍
前端中的工厂模式是一种创建对象的设计模式，它可以让我们封装创建对象的细节，我们使用工厂方法而不是直接调用 new 关键字来创建对象，使得代码更加清晰、简洁和易于维护。在前端开发中，工厂模式通常用于创建多个相似但稍有不同的对象，比如创建一系列具有相同样式和行为的按钮或者表单。
工厂模式的流程
+------------------+| Client |+------------------+|| requestsV+------------------+| Factory |+------------------+|| selectsV
+---------------------+
| Concrete Factory |
+---------------------+|| createsV
+---------------------+
| Concrete Product |
+---------------------+|| returnsV+------------------+| Client |+------------------+- 客户端（Client）向工厂对象发出请求。
- 工厂对象（Factory）根据客户端的请求选择合适的具体工厂。
- 具体工厂（Concrete Factory）创建所需的具体产品（Concrete Product）对象。
- 工厂将创建的对象返回给客户端。
例子
class Product {constructor(name) {this.name = name}init() {console.log('init')}fun() {console.log('fun')}
}class Factory {create(name) {return new Product(name)}
}// use
let factory = new Factory()
let p = factory.create('p1')
p.init()
p.fun()
场景
- 如果你不想让某个子系统与较大的那个对象之间形成强耦合，而是想运行时从许多子系统中进行挑选的话，那么工厂模式是一个理想的选择
- 将new操作简单封装，遇到new的时候就应该考虑是否用工厂模式；
- 需要依赖具体环境创建不同实例，这些实例都有相同的行为,这时候我们可以使用工厂模式，简化实现的过程，同时也可以减少每种对象所需的代码量，有利于消除对象间的耦合，提供更大的灵活性
优点
- 创建对象的过程可能很复杂，但我们只需要关心创建结果。
- 构造函数和创建者分离, 符合“开闭原则”
- 一个调用者想创建一个对象，只要知道其名称就可以了。
- 扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
缺陷
增加了类的数量引入工厂模式会增加代码的复杂度，因为需要定义接口、具体工厂和具体产品等额外的类，从而增加了类的数量。
不易于扩展如果需要添加新的产品类型，就需要修改工厂类的逻辑，这违反了开闭原则（对扩展开放，对修改关闭）。
难以理解对于简单的项目，引入工厂模式可能会增加不必要的复杂性，使代码难以理解。
静态工厂方法不易被继承如果使用静态工厂方法来创建对象，则无法通过继承改变所创建的产品类型。
增加了代码的抽象程度工厂模式引入了额外的抽象层，使得代码更加抽象，可能增加理解和调试的难度。
后言
创作不易，要是本文章对广大读者有那么一点点帮助 不妨三连支持一下，您的鼓励就是博主创作的动力