我们一般制造对象时，采用操作符new来进行创建。但是慢慢我们了解到实例化这个活动不应该总是公开地进行，同时初始化还经常造成“耦合”的问题。
如果我们不希望出现上述问题，那么我们就有必要认识一下“工厂模式”，它将有助于我们从复杂的依赖中解脱出来。
1）为什么说“new”不好？
当看到“new”，就会想到“具体”。
我们不应该总是针对实现编程，但是当我们每次使用new时，正是在针对实现编程而不是接口，这很不符合我们的期望。
当使用“new”时，我们的确是在实例化一个具体类，当代码绑着具体类会导致代码更脆弱，更缺乏弹性。
当看到这样的代码，一旦有变化或扩展，就必须重新打开这段代码进行检查和修改。通常这样修改过的代码将造成部分系统更难维护和更新，而且也更容易犯错。
针对接口编程，可以隔离掉以后系统可能发生的一大堆改变。
2）我们现在建立一个拥有多种披萨类型的披萨店
通常，我们为了让系统有弹性，我们将各种类型的披萨都继承于一个抽象类或接口。（但是这样做会导致这些类或者接口无法直接实例化）
这么编程，我们就会承受一些压力，这些压力来自于增加或删除比萨类型
这时候，我们想到回到OO设计原则去寻找线索。我们发现这么一条“找出会变化的方面，把它们从不变的部分分离出来”。
那么，现在我们最好将创建对象移到orderPizza()之外，这就需要把创建披萨的代码移到另一个对象中，由这个对象专职创建披萨。
3）定义简单工厂
4）工厂方法模式
现在我们为上述我们建立的披萨店开设加盟店。
我们希望每个加盟店有自己独特的风味，但是为了保证品牌的一致性，虽然风味可以不同，但披萨的制作流程火候必须一致。
甚至我们可以上不想子类覆盖的方法orderPizza（）声明成final。
开一家披萨店，举个例子。
实现一个独特风味的披萨，举个例子。
调用，测试一下。
5）依赖倒置原则
6）抽象工厂模式
7）小结
OO基础：
- 抽象
- 封装
- 多态
- 继承
OO原则：
- 封装变化
- 多用组合、少用继承
- 针对接口编程，不针对实现编程
- 为交互对象之间的松耦合设计而努力
- 对扩展开放，对修改关闭
- 依赖抽象，不要依赖具体类
OO模式：
- 策略模式——定义算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户
- 观察者模式——在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新
- 装饰者模式——动态地将责任附加到对象上。想要扩展功能，装饰者提供有别于继承的一种选择
- 抽象工厂模式——提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类
- 工厂方法模式——定义了一个创建对象的接口，但由于子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类
要点：
- 所有的工厂都是用来封装对象的创建
- 简单工厂，虽然不是真正的设计模式，但仍不失为一个简单的方法，可以将客户程序从具体类解耦
- 工厂方法使用继承：把对象的创建委托给子类，子类实现工厂方法来创建对象
- 抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中
- 所有工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合
- 工厂方法允许类将实例化延迟到子类进行
- 抽象工厂创建相关的对象家族，而不需要依赖它们的具体类
- 依赖倒置原则，指导我们避免依赖具体类型，而要尽量依赖抽象
- 工厂是很有威力的技巧，帮助我们针对抽象编程，而不是针对具体类编程
参考书目：《Head First 设计模式》
原文地址：https://www.cnblogs.com/dudududu/p/9126073.html