工厂设计模式
创建行模式-工厂设计模式
简单工厂模式
根据不同的参数，返回不同的创建实例对象，
模式结构
- Factory 工厂角色
负责创建所有实例的内部逻辑
- Product （抽象产品角色）
所有创建实例的-抽象接口
- ConcreteProduct: 具体的产品角色
实现抽象接口的的实现者
优缺点
- 优点
0、隐藏了创建对象的细节
0、无需知道具体 类名/结构体名 ，只需要知道对应参数即可
- 缺点
0、新增产品类型，就要修改 创建工厂方法，违背了开闭原则，
0、工厂类集合了，所有的产品的创建逻辑，一旦出现问题，则整个系统就会受到影响。
适用场景
- 工厂创建的对象类型比较少，不会造成工厂方法中的业务逻辑太复杂
- 不需要关心创建细节，甚至连类名都不需要知道，只需要知道类型对应的参数
工厂方法模式
解决 【简单工厂】的缺点，将工厂进行抽象（接口），让具体的产品工厂，创建对应的产品，将压力进行扩散到对应的 产品工厂
模式结构
- Factory 抽象工厂
产品工厂的抽象接口
- ConcreteFactroy 具体的工厂
具体的产品的工厂
- Product （抽象产品角色）
所有创建实例的-抽象接口
- ConcreteProduct: 具体的产品角色
实现抽象接口的的实现者
优缺点
- 优点
0、新增产品类型时，不需要修改代码，只需要新增 对应 产品工厂 和 产品对象，扩展性好，符合开闭原则。
0、关注的点 由【产品参数类型】变为，对应的【产品工厂类型】
0、避免 创建者 和 具体产品之间的 紧耦合。
- 缺点
新增产品，则需要新增新的子实现（具体工厂，具体的产品）个数将成对增加，增加了系统的复杂度。
使用场景
如果你希望用户能扩展你软件库或 框架库的内部组件，可使用工厂方法
比如你写了一个开源lib库，并且准备使用工厂设计模式，要求在不修改源代码的情况下，并且具有开闭原则，则 【工厂方法】最适合了，开发者完全可以根据 【接口】自定义实现 扩充。
抽象工厂模式
创建一系列的相关对象或相互依赖的对象接口，不需要指定具体的子类。
模式动机
在工厂方法中，具体的工厂对应一种具体的产品，但是有时候我们需要一个工厂可以 提供多个产品对象。
产品族：同种工厂的 不同产品，（海尔工厂-【冰箱，洗衣机，电视】）
产品等级结构：即产品的继承结构，对产品的抽象，不同的实现，【电视的产品的抽象，海尔电视，长虹电视等】
模式结构
- Factory 抽象工厂
产品工厂的抽象接口，抽象工厂的里面的方法不再是单一的创建【产品】方法，而是一系列的 创建不同的产品对象。
- ConcreteFactroy 具体的工厂
具体的产品的工厂
- Product （抽象产品角色）
所有创建实例的-抽象接口
- ConcreteProduct: 具体的产品角色
实现抽象接口的的实现者
优缺点
- 优点
0、可以确保同一工厂生产的产品相互匹配
0、开闭原则，（向 应用程序引入新的产品变体 （增加新的工厂和产品族容易）时，不需要修改客户端代码，）
0、单一职责，（将产品的生成代码，抽取到统一位置，便于维护）
- 缺点
0、由于采用该模式需要向应用中引入众多接口和类， 代码可能会比之前更加复杂
0、在添加新产品时候，难以扩展抽象工厂来生产新的产品对象。（需要修改所有的子工厂的实现）
0、开闭原则的倾斜性（增加新的工厂和产品族容易，但是增加新的产品等级结构麻烦）
使用场景
- 系统有多于一个的产品族，且每次都使用某一个产品族
