type
status
date
slug
summary
tags
category
icon
password
工厂模式有三种，简单工厂模式、工厂方法模式和抽象工厂模式，工厂模式名气很大但是使用场景并不多，一方面是代码复杂生产一个对象要新建接口和工厂类，使用时也要先生成工厂对象，另一面是大多数场景生成对象并不需要如此复杂的逻辑，相比它的优点（解耦，单一职责）这种模式带来的复杂度可能更印象开发
使用场景
生成对象的逻辑较为复杂时
优缺点
优点：
创建对象逻辑与业务代码逻辑的解耦
缺点：
代码臃肿
简单工厂模式
角色
- 简单工厂SimpleFactory：负责创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。
- 抽象产品IProduct：简单工厂创建的多有对象的父类，负责描述所有实例共有的公共接口。
- 具体产品ConcreteProduct
模板代码
简单工厂模式的缺点是：每当具体产品类的抽象产品类增多时，会需要在简单工厂类中新增关于新增产品类对象生成的方法。当抽象产品类很多时，抽象工厂会很臃肿。并且在这种情形下，SimpleFactory类也不符合开闭原则。
工厂方法模式
定义创建对象的接口，但具体实现放到实现这个接口的管理具体一类产品的对象生成的工厂类中去实现。
角色
- 抽象工厂:定义了创建抽象产品的方法，任何在模式中创建对象的工厂类都必须实现这个接口
- 具体工厂:实现抽象工厂接口的具体工厂类，负责生产具体的产品
- 抽象产品:工厂方法模式所创建的对象的超类型。也是产品对象的共同父类或者共同拥有的接口
- 具体产品:实现了抽象产品角色所定义的接口。某具体产品由具体工厂创建，他们往往一一对应
模板代码
从简单工厂模式的讲述知道：简单工厂的一个缺点在于，每当需要新增产品时，都需要修改负责生产产品的SimpleFactory类，违背了“开闭原则”，并且会使SimpleFactory类十分的臃肿。而使用工厂方法模式后，当新增ProductC时，只需要对应创建具体产品类ProductC和负责生产ProductC的具体工厂FactoryC即可。符合“开闭原则”，便于扩展。
它的缺点也很明显：类的个数容易过多，增加复杂度，实现抽象工厂接口的具体工厂只能生产出一种产品（可以用抽象工厂模式解决）。
在我看来这种模式就是为了符合开闭原则设计的，在开发中没有必要这样做。
抽象工厂模式
抽象工厂模式在工厂方法模式的基础上进行进一步抽象。设想下面这种场景：
现有两种具体产品（具体产品）：篮球，足球（在此基础上的抽象产品可看成球）。同时，对于足球和篮球来说，他们都有两种品牌安踏、李宁。
如果采用工厂方法模式解决上述场景中创建产品的问题，需要在抽象工厂中定义创建产品的方法，并新建四个用于创建具体产品的具体工厂类：用于创建“李宁篮球”的具体工厂，用于创建“李宁足球”的具体工厂，用于创建“安踏篮球”的具体工厂，用于创建“安踏足球”的具体工厂。
从上面的解决方式可以看出：使用工厂方法模式，创建了很多具体工厂类，而没有利用产品的“商品族”的概念。
由此引出，抽象工厂模式是用于解决“一类产品”的创建问题（在上述场景中，可以把“李宁篮球”，“李宁足球”，“安踏篮球”，“安踏足球”归纳为：“篮球”，“足球”这两类商品）
角色
- 抽象工厂：声明创建抽象产品对象的一个接口（有几个产品组，则声明几个方法。比如对于上述的场景，需要声明一个用于生产篮球类产品的方法，还需要声明一个用于生产足球类产品的方法）
- 具体工厂：实现创建具体产品对象的操作
- 抽象产品：为一类产品对象的抽象
- 具体产品：定义一个将被相应的具体工厂创建的产品对象（比如上述场景中的：李宁篮球）
模板代码
可以看到，抽象工厂模式需要两个工厂，而工厂方法模式需要4个工厂，他们的区别就是抽象工厂定义了可以生产两种产品，从而减少的重复类的创建。
📎 参考
- 作者:LuluNotion
- 链接:https://tangly1024.com/article/design-pattern-factory
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章