工厂方法模式
工厂方法模式，简单来说是来为了解决简单工厂模式所出现的一些缺点而进行的改进。
传送门→
通过上篇简单工厂模式的介绍，现在来看下实现代码的uml图
在简单工厂中我们实现了
- 开大卡车的A级驾照司机
- 开小汽车的C级驾照司机
现在需增加一个开中型汽车的B级驾照司机，我们用简单工厂模式应该怎么做呢？
- 我们需要增加IDriver的具体实现，就是增加一个中型汽车司机类
- 修改工厂 源码 ，增加返回中型汽车司机的判断逻辑
每添加一个业务逻辑，都要修改源码，显然不符合开闭原则，所以就有了工厂方法模式。提供一个抽象工厂方法模式，这样就可以避免新增的时候修改源代码，只要新建一个类来继承了工厂方法模式即可。
模式的结构与实现
工厂方法模式由抽象工厂、具体工厂、抽象产品和具体产品等4个要素构成
- 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法 new Product () 来创建产品。
- 具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
- 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
- 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。
现在我们开始改造前面的简单工厂模式实现的司机开车的代码，一个产品对应一个具体的工厂实现，还是比较麻烦，我们要怎么做才能避免这种麻烦呢？下面实现过程利用 泛型 和反射针对此做了些改进
1、抽象工厂方法
泛型
2、具体工厂方法
反射
3、抽象产品
4、具体产品
现在工厂方法模式已经实现了
代码关系结构
测试下吧
测试
测试结果
工厂方法模式的优缺点
优点 ：
在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户端隐藏了哪种具体产品类将被 实例化 这一细节，用户只需要关心所需要产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
基于工厂角色和产品角色的多态性设计是工厂方法的关键，他能够让 工厂模式 自主的创建产品对象，而如何创建这个对象的细节完全封装在工厂类。
使用工厂方法模式最大的优点就是你新加类的时候不用动源代码，只要写新的产品新的工厂来继承对应的类就行了。
缺点：
既是优点又是缺点，你要新加类型的时候，既要创建产品类，又要创建工厂类，增加了一大波类。在一定的程度上增加系统的复杂度。（ps:利用泛型和反射已经解决了一个产品对应一个工厂类的问题了）
由于考虑到系统的扩展性，需要引入抽象层，在客户·端代码中均用抽象定义，难以理解！
工厂方法模式场景
1、客户端不知道它所需要的对象的类，在工厂方法模式中，客户端不需要具体产品类的类名，只需要知道所对应的工厂即可，具体产品对象由具体工厂类创建，可见具体产品类的类名在配置文件或者数据库中存在！
2、抽象工厂类通过其子类来指定创建那个产品类，用父类来新建子类可以提高可扩展性。
更多干货请关注
~~~///(^v^)~~~
欢迎分享，原创文章。
