<抽象工厂>比<工厂方法>多了啥（区别）

前言：仅当复习讨论，写得很差，多多指教!

上一篇文章《 <工厂方法> 比 <简单工厂> 多了啥 》介绍了简单工厂模式和工厂方法模式。本篇文章则讲最后一个工厂----抽象工厂。若是对工厂方法比较模糊的，能够返回上一篇文章复习。接下来先看故事。

抽象工厂模式

UML

  又通过三年以后，中国已经愈来愈国际化了，不少日本人来中国留学也带来了本土的猫和狗。一旦他们留学回去以后，就把这些动物送到了动物流浪工厂中。此时，个别对小日本有抵触的人并不想为这些日本的动物喂食，因而拉起一部分人到工厂去抗议，要求本身的食物只给中国的动物吃，把日本的动物赶出去。厂长一看这么多人抗议，没办法，只能把动物分国籍了，因而把中国流浪动物在一个工厂，日本流浪动物在另一个工厂。
  某一天，一位原本认为日本的动物也是动物的爱心人士看到了安培晋三参拜靖国神社的新闻，因而她要求原来喂养的日本流浪动物 切换 到中国流浪动物，以下图所示，她只要切换一个工厂就能够达成心愿。

对比一下业务场景

概念

  抽象工厂模式：为建立一组相关或相互依赖的对象提供一个接口，并且无需指定他们的具体类。（如上图，提供了数据库抽象工厂，而无需指定具体数据库给客户端）

优势

1. 最大的好处就是易于交换产品体系（sqlserver 替换成 oracle），因为具体工厂类，例如sql server工厂在一个应用中只须要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得很是容易，它只须要改变具体工厂便可使用不一样的配置。
2. 它让具体的建立实例过程与客户端分离，客户单是经过它们的抽象接口操做实例，产品的具体类名也被具体工厂的实现分离，不会出如今客户端代码中（好比sqlserverUser, 客户端只知道抽象类，不关心你是用sql server仍是用oracle来实现。所有都依赖抽象，符合依赖倒置原则）

缺点

1. 若是更换 产品体系，改动的工做量很是大，由于处处都有 IFactory factory=new SqlserverFactory()的实现。这么实例化1000次，就要改1000次。
2. 增长一个功能，要涉及到增长三个类和修改三个工厂，这。。。比较累人。

改进

  针对以上两个问题，来进行解决。1.可不可动态实例化？2. 增长类是可扩展的，可是修改三个工厂是否能够去掉？

  答案是：能够的，利用反射+配置文件

UML

  咱们将工厂干掉，利用数据库Context类来动态实例化具体的功能类（产品类）。利用反射来实例化相关的实例，而不是让工厂去实例化，实例化格式以下：
  Assembly.Load(“程序集名称”).CreateInstance(“命名空间.类名称”)

客户端实现方式

数据库Context代码以下：

class 数据库Context
{
    private static readonly string db=ConfigurationManager.Appsettings["DB"];
    private static readonly string AssemblyName="程序集名称"；

    public static IUser 增长用户（）
    {
     string className=AssemblyName+".User";
     return  (IUser)Assembly.Load(AssemblyName).CreateInstance(className);
    }
  
//其余相似
}

总结

介绍完了抽象工厂模，可是它跟工厂方法的差别在哪里？

1. 每个模式都是针对必定问题的解决方案，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式针对的是多个产品等级结构。
2. 工厂方法模式是必定要利用工厂抽象类的，这个是包含在它的定义中的。而抽象工厂模式进阶中已经干掉了抽象工厂类，去利用反射进行实例化。
3. 在实际项目中,更换数据库是有可能的, 好比某个数据提供商数据量大的时候不够稳定,此时通过商讨,要更换数据提供商,这里就涉及到很大的扩展性问题了。