三种工厂模式总结
简单工厂模式
优点
使用户根据参数获得对应的类实例，避免了直接实例化类，降低了耦合性。
缺点
可实例化的类型在编译期间已经被确定，如果增加新类型，则需要修改工厂，违背了开放封闭原则 。 简单工厂需要知道所有要生成的类型，当子类过多或者子类层次过多时不适合使用。
简单工厂模式中的三个角色
- Factory：工厂角色
对应本文中的SimpleFactory类 - Product：抽象产品角色
对应本文中的Pizza - ConcreteProduct：具体产品角色
对应本文中的CheesePizza类和GreekPizza类
- 工厂角色（Creator）： 是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。
- 抽象产品角色（Product）： 是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。
- 具体产品角色（Concrete Product）： 继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。
工厂方法模式
优点
-
更符合开-闭原则
新增一种产品时，只需要增加相应的具体产品类和相应的工厂子类即可
简单工厂模式需要修改工厂类的判断逻辑 -
符合单一职责原则
每个具体工厂类只负责创建对应的产品
简单工厂中的工厂类存在复杂的switch逻辑判断 -
不使用静态工厂方法，可以形成基于继承的等级结构。
简单工厂模式的工厂类使用静态工厂方法
缺点
- 添加新产品时，除了增加新产品类外，还要提供与之对应的具体工厂类，系统类的个数将成对增加，在一定程度上增加了系统的复杂度；同时，有更多的类需要编译和运行，会给系统带来一些额外的开销；
- 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。
- 虽然保证了工厂方法内的对修改关闭，但对于使用工厂方法的类，如果要更换另外一种产品，仍然需要修改实例化的具体工厂类；
- 一个具体工厂只能创建一种具体产品
作用
将类的实例化（具体产品的创建）延迟到工厂类的子类（具体工厂）中完成，即由子类来决定应该实例化（创建）哪一个类。
角色
抽象产品（Product）： 具体产品的父类，描述具体产品的公共接口
具体产品（Concrete Product）： 抽象产品的子类，工厂类创建的目标类 描述生产的具体产品
抽象工厂（Creator）： 具体工厂的父类，描述具体工厂的公共接口
具体工厂（Concrete Creator）： 抽象工厂的子类，被外界调用 描述具体工厂；实现Factory工厂方法创建产品的实例
应用场景
- 当一个类不知道它所需要的对象的类时
在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可； - 当一个类希望通过其子类来指定创建对象时
在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。 - 将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。
抽象工厂模式
为什么出现抽象工厂模式
当我们一个小品牌的汽车厂做成大的汽车厂时，这时我们不仅仅，满足与只是创建昂贵的汽车和便宜的汽车，而这时我们更趋向于生产不同系列的汽车
但是问题来了牌子还时这个牌子但是我现在生产的汽车不同了，所以我需要同的厂来生产不同系列的车因为这样才能做到高效，因为制作车的流程没有改变
但是不同系列车的优点也有不同，这时我们的抽象工厂就发挥了大作用了。
角色
- 抽象工厂（Abstract Factory）角色：它声明了一组用于创建一族产品的方法，每一个方法对应一种产品。
- 具体工厂（Concrete Factory）角色：它实现了在抽象工厂中声明的创建产品的方法，生成一组具体产品，这些产品构成了一个产品族，每一个产品都位于某个产品等级结构中。
- 抽象产品（Abstract Product）角色：它为每种产品声明接口，在抽象产品中声明了产品所具有的业务方法。
- 具体产品（Concrete Product）角色：它定义具体工厂生产的具体产品对象，实现抽象产品接口中声明的业务方法。
优点
- 抽象工厂隔离了具体类的生成，是的客户端不需要知道什么被创建。所有的具体工厂都实现了抽象工厂中定义的公共接口，因此只需要改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。
- 当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。
- 增加新的产品族很方便，无须修改已有系统，符合“开闭原则”。
缺点
- 添加新的行为时比较麻烦。如果需要添加一个新产品族对象时，需要更改接口及其下所有子类，这必然会带来很大的麻烦。
适用场景
- 系统中有多于一个的产品族。 而每次只使用其中某一产品族。可以通过配置文件等方式
来使得用户可以动态改变产品族，也可以很方便地增加新的产品族。 - 产品等级结构稳定。设计完成之后，不会向系统中增加新的产品等级结构或者删除已有的产品等级结构
最后的话：
这篇文章是我用来记录学习和总结的学习笔记，只为了加强自身理解，如果有哪里不对的地方，还请各路大佬指正。目前理解的很浅显。