判断标准
要不要使用工厂模式的最本质的参考标准。
- 封装变化：创建逻辑有可能变化，封装成工厂类之后，创建产品逻辑的变更对调用者更明确。
- 代码复用：创建代码抽离到独立的工厂类之后可以复用。
- 隔离复杂性：封装复杂的创建逻辑，调用者无需了解如何创建对象，迪米特法则。
- 控制复杂度：将创建代码抽离出来，让原本的函数或类职责单一，代码简洁。
举个栗子：
- 简单工厂
- 到M记，要一份薯条、汉堡、可乐
- 问题，要分别点三次，而且吃不到其他品牌的东西
- 工厂方法
- 到M记，要一份汉堡套餐（不同套餐对应不同的工厂子类）
- 问题：而且吃不到其他品牌的东西
- 抽象工厂
- 到某团， 选中M记，购买一份汉堡套餐
理解、实现、问题：
- 简单工厂( 静态工厂方法模式)
- 允许工厂类创建对象，可以隐藏产品创建的具体逻辑。
- 问题：预设所有对象类型，后续拓展麻烦
- 工厂方法
- 允许工厂接口创建对象，但由继承工厂的子类去处理创建产品的过程。
- 使用继承，把对象的创建委托给子类，由子类来实现创建方法，可以看作是抽象工厂模式中只有单一产品的情况。
- 问题1：得提前知道工厂子类
- 问题2：每次增加一个产品时，都需要增加一个具体产品类和对应子工厂。
- 问题3：具体的产品类必须属于同一父类，或者实现同一接口
- 抽象工厂
- 多种类型的产品，每一个类型的产品的创建都由各自实现同一抽象工厂方法的子工厂去负责。
- 工厂模式可以帮助我们针对抽象/接口编程，而不是针对具体类编程，在不同的场景下按具体情况来使用。
- 问题：某一种类型的产品，增加的话还是得新增具体产品类和修改对应抽象工厂方法的子工厂的创建逻辑（问题同简单工厂）
- 问题：如果要新增某一种类的话，需要在抽像工厂新增对对应抽象方法，所有子工厂都得跟着修改，然后得新增对应种类的子工厂
