最近在看一些行业优秀的开源项目,感触颇深,特别是从代码质量和项目质量来说,系统与系统的解耦合,模块与模块的抽离,代码与代码的复用性等方面,于是想着把之前自己的文章重新梳理一下,当做一个笔记资料,同时也会借鉴一些市面上优秀的文章作参考,如各位同学有不同的见解,也希望不吝赐教,批评指正,多交流.
工厂模式：定义一个创建产品对象的工厂接口，将产品对象的创建行为在子类中实现;
按实际业务场景划分，工厂模式有 3 种不同的实现方式，分别是:
- 简单工厂模式;
- 工厂方法模式;
- 抽象工厂模式;
简单工厂模式（Simple Factory Pattern）：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。因为在简单工厂模式中用于创建实例的方法是静态（static）方法，因此简单工厂模式又被称为静态工厂方法（Static Factory Method）模式，它属于类创建型模式。
我们来看下简单工厂模式的实现:
优点：
- 工厂类包含必要的逻辑判断，可以决定在什么时候创建哪一个产品的实例。客户端可以免除直接创建产品对象的职责，很方便的创建出相应的产品。工厂和产品的职责区分明确。
- 客户端无需知道所创建具体产品的类名，只需知道参数即可。
- 也可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。
缺点：
- 简单工厂模式的工厂类单一，负责所有产品的创建，职责过重，一旦异常，整个系统将受影响。且工厂类代码会非常臃肿，违背高内聚原则.
- 使用简单工厂模式会增加系统中类的个数（引入新的工厂类），增加系统的复杂度和理解难度.
- 系统扩展困难，一旦增加新产品不得不修改工厂逻辑，在产品类型较多时，可能造成逻辑过于复杂.
应用场景
对于产品种类相对较少的情况，可以考虑使用简单工厂模式。使用简单工厂模式的客户端只需要传入工厂类的参数，不需要关心如何创建对象的逻辑，可以很方便地创建所需产品,但在相对产品场景比较多的情况下,或者需要增加产品的情况下,工厂类需要不断的改变,因此简单场景只能应对简单情况下的开发,而要做复杂一些的生产场景开发,则需要用到工厂模式:
工厂模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
我们来看下工厂模式的实现:
从工厂模式看来,我们解耦了对产品的操作,每种操作都作为一种工厂类,做到了工厂隔离,后续如果需要新的产品,则只需要根据定义产品即可,再设计新的工厂生产产品,不过,这样做也有个问题,就是调用对应的工厂类时,需要实例化不同的工厂,会让程序看起来那还有没有一种方式,是可以解决这种问题的呢,接下来,我们看一下抽象工厂吧:
抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
我们来看下抽象工厂模式的实现: