《Head First 设计模式》笔记4 工厂模式

问题：实现的代码里不能有new，一出现new，一旦加入新的具体类，就必须改变代码。也就是说，你的代码并非”对修改关闭”。想用新的具体类型来扩展代码，必须重新打开它。

由此提出一个疑问：如何将实例化具体类的代码从应用中抽离，或者封装起来，使他们不会干扰应用的其他部分？

简单工厂：

简单工厂的特点是它有一个“工厂”对象，该对象除了负责创建新Pizza之外什么也不做，PizzaStore作为“工厂”对象的客户，调用该工厂创建对象的方法来得到新的Pizza。“工厂”创建的一切比萨都遵循Pizza接口，从而让PizzaStore调试好的orderPizza方法能够对工厂传来的Pizza进行操作（prepare()、bake()、cut()等）。

允许子类做决定型工厂：
如果你希望制作比萨的流程由PizzaStore决定，而各个加盟店又能弹性地制作自己的Pizza，则可以把createPizza方法（从工厂对象）移回到PizzaStore中。通过在PizzaStore()定义好orderPizza的具体实现，从而固定住Pizza的制作流程，同时把createPizza()声明成一个抽象方法，来让子类决定自己所做Pizza的风味，从而达到目的。

由于createPizza的返回值类型遵循Pizza接口，所以超类中定义的orderPizza实现可以对该Pizza做各种操作而无需知道是哪些实际的具体类型Pizza进来了。

工厂方法模式（Factory Method Pattern）：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类中。

上面的“允许子类做决定型工厂”即是工厂方法模式。

工厂方法模式类图：

工厂方法模式比简单工厂到底好在哪里：没搞懂。
参考：https://www.toolsou.com/article/200846462

思考：工厂模式的一个优点是，把创建对象的代码用栅栏围了起来，就像你把所有的羊毛堆到眼前一样，一旦围起来后，就可以保护这些创建对象的代码。如果让创建对象的代码到处乱跑，代码容易出问题。

依赖倒置原则：
要依赖抽象，不要依赖具体类。

首先，这个原则听起来很像是“针对接口编程，不针对实现编程”，不是吗？的确很相似，然而这里更强调“抽象”。这个原则说明了：不能让高层组件依赖底层组件，而且，不管高层或底层组件，“两者”都应该依赖于抽象。

其中，所谓“高层”组件，是由其他底层组件定义其行为的类。例如，PizzaStore是额高层组件，因为它的行为是由比萨定义的：PizzaStore创建所有不同分比萨对象，准备、烘烤、切片、装盒；而比萨本身属于底层组件。

几个指导方针帮助你遵循此原则：

抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而需要明确指定具体类。

比萨店的抽象工厂类类图：