昨日睡前重温了下之前阅读过的 设计模式 Head First系列中的工厂模式
有点温故而知新的感觉
故记之
工厂，在一般生活当中，充当的一个角色应该是：生产车间
也就是加工原料，产出产品的地方。
这其实也是软件的本质，计算机的本质
根据输入，输出数据
什么意思呢？我们先来看看简单工厂的例子
public Foot createFoot (Material material) {if (material.getName().equals("flour")) {return new Noodles("noodles");} else if (...) {...... } }
首先说明的是简单工厂并不是一种模式，只是一种编码习惯。
ok，然后我们来看看，我们的入餐是材料（食材），产出是食物。
这就是第一个工厂模式的特色，尽管简单工厂并非模式--产出产品（有时候我们会省略掉食材，因为工厂有自己的原料供给）
接着我们来看看抽象模式
抽象这个词，我最早接触的时候是初中学几何的时候，这抽象可不是我们所说的抽象类 abstract class，请别搞错
其实抽象这个词，在这里我们更接近的是接口，因为抽象是将通俗意义上的特性总结成具有一定专业性的公式或语言
而接口确确实实的是一个未实现的特征，只有我们实现了接口，它才是具体的
所以我们所说的抽象工厂，实际上是以接口实现的，与工厂模式的继承方式相反，这后续再讨论
这边代码看起来比较“抽象”，所以我们还是用uml图来看吧
我有些偷懒，故此没有多列
显而易见，工厂接口（抽象）下，有多个实现工厂接口的具体工厂
就是说抽象工厂只是告诉我们需要创建什么，自有具体的工厂去负责
那么，我们看起来，好像这个模式没什么特别的，就是一个接口来让多个类实现而已？
它实际解决了什么问题呢？
自然是解耦了，我们不需要在代码中直接看到new
不理解？就是把创建对象的代码解耦咯，这其中的一个关键点还体现了高内聚，低耦合的特性
也就是说，创建原料的工厂，里面的各种原料都是服务于要生成的产品，很可能是相互依赖的，这就是高内聚
而创建产品，与需要使用产品的场景是不需要有太大关系的
例如你买一台手机，你会觉得你想要跟生产它的工厂聊聊人生，谈谈理想吗？
好吧，接下来，我们再看看这个词汇：依赖反置
也就是说，低级组件不可依赖高级组件
试想，专卖店中的手机会因为没有一个专卖店，就没有其他人卖吗？
那，低级组件不就是手机吗，高级组件不就是手机专卖店吗
换言之，需要大卖手机的时候自然就有了手机专卖店，这不就是依赖倒置的原理吗？--除非必要，别来call我
so：除非你需要在泉州卖iphone6，否则你就不需要开专卖店
所以我们接下来要讲的是工厂模式，也同样是用于实践依赖倒置原则的方式
只是与抽象工厂不同的是，工厂模式用的是继承
首先，我们会有一个抽象类，里面大部分的代码是复用的，但唯有一个抽象方法
这其实与模板模式相似，将创建产品的具体方法延迟到子类中决定
手机工厂有自己的决定权，决定自己要如何去生产手机，在实际场景中适用的就是所谓的加盟店的自主权