目录
一切设计模式的目标，就是让我们的程序更容易的进行一个扩展 扩展
1. 工厂模式的核心本质
- 工厂模式是创建型模式，所以他是用来创建对象用的
- 用工厂类来帮助我们创建
- 将选择实现类、创建对象统一管理和控制。从而将调用者跟我们的实
现类解耦。
1.1 适合的场景
- 创建的对象较为复杂。因为封装了对象的实例化细节，尤其是对于实例化较复杂或者对象的生命周期应该集中管理的情况。会给你系统带来更大的可扩展性和尽量少的修改量。
- 在软件开发中，当我们用到大量的创建某种、某类或者某批对象时，可以用到工厂模式。
2. 没有使用设计模式
- 用来生产同一等级结构中的任意产品。（对于增加新的产品，需要修改已
有代码）
2.1 场景模拟：
- 现在有这么一个场景：
- 我是一个普通的人。我想要一台电脑，具体要怎么办呢？
- 如果没有工厂的话，是不是我们需要自己买东西，买各种配件，然后自己组装创建一个 电脑，这样需要我们啥都要知道。
- 如果有工厂的话，我们直接花钱找工厂拿一个就ok了，我们什么都不用知道，就只用跟他说，我们要一个电脑，再给点钱，就ok了。
2.2 coding没有使用设计模式
其中 Client 类代表我
2.2.1 类图
2.2.2 存在的问题
- 我Client 对象 要创建一个电脑，要知道的东西太多。所依赖的东西也是很多。耦合度比较高
- 看图
3. 使用简单工厂模式
3.1 类图
3.2 优点(client代码在里面)
- 调用者只需要知道创建什么对象即可
- 屏蔽了创建对象的具体实现。调用者只需要关心接口。
- 调用者代码：
3.3 存在的问题
- 对于增加新产品无能为力！不修改代码（工厂的代码）的话，是无法扩展的。
- 看图：
- ocp原则： 开闭原则,对扩展开放，对修改关闭。
- 我们修改了工厂的代码，违反了ocp原则，从设计原则上来说，是不好的。但是简单工厂模式，如果在我们软件项目中使用，感觉还是可以容忍的。
4 工厂方法模式
- 工厂方法模式解决了 简单工厂模式，不满足ocp的问题。但是又势必带来了一些其他问题，总的来说各有千秋。
4.1 类图
- 详细的依赖关系，就不画出来了，如果画出来就太乱了。
4.2 client 代码
4.3 优点
- 工厂方法模式说白了，就是解决了简单工厂模式不满足ocp原则的问题
- 工厂方法模式和简单工厂模式最大的不同在于，简单工厂模式只有一个（对于一个项目或者一个独立模块而言）工厂类，而工厂方法模式有一组实现了相同接口的工厂类。
- 如何扩展，看图
- 需求：增加了一个小米工厂，该如何扩展？
4.4 存在的问题
- 结构复杂
- 代码复杂
- 类太多了，多的一批，多一个产品，我就加一个类。
5. 抽象工厂模式
- 抽象工厂模式，个人认为，并不是前面两个的升级版，而是可以应对不同的场景。
- 用来生产不同产品族的全部产品。（对于增加新的产品，无能为力）扩展产品族方便。
- 适用有多个产品族，而且其内的产品长期不会变化的场景。
5.1 什么是产品族？
- 假设家电品牌有，海尔，美的。而且他们都有 空调，冰箱，电视产品。且假设他们的产品长期不会变化，都只要空调，冰箱，电视。（假设）
5.2 类图
- 试试idea？如果展示出所有的依赖关系？？？
- 用eclipse自己画，画出比较重要的依赖关系，其他的依赖关系看上图。
5.3 client 代码
5.4 优点
- 对扩展产品族的支持较好。
5.5 注意
- 不支持扩展产品族中的产品。这样会修改很多代码。
- 比如想增加一个洗衣机。看图解释。
5.6 如何扩展产品族
- 比如扩展一个海尔的产品族，如何操作呢？
- 从上图可以看出。满足原则。增加新的功能，并不会修改原有的代码