持续改进，抽象工厂也反射
在我的上一篇文章(疑惑？改良？从简单工厂到工厂方法)中，详细论述了创建模式中简单工厂到工厂方法的演变过程，并试图结合工厂方法的设计以及.net中的反射机制之所长，改良出一种新型的工厂—反射工厂，这当然不是我的首创，经典的PetShop 中便有此工厂的身影。本文尝试按照前篇文章的思路，借着工厂方法到抽象工厂的演变过程而继续对抽象工厂进行改良，文章中的思想仅代表了作者当时的观点，有欠妥的地方，还请各位不吝赐教。
工厂模式
前面的文章提到了简单工厂和工厂方法其实是一码事，他们完成了将客户对产品功能的使用与创建具体产品职责的分割，不同的只不过是他们实现方式上的差异，工厂方法利用更加优雅的多态性取代了相对ugly的switch case…语句，从而很好的体现了设计原则中的OCP原则，此文章将不再强调这种实现上的差异性，而更多的强调两者之间设计思路上的共性，并将这种共性统称成为工厂模式,从而进一步与抽象工厂进行对比。
工厂的使用，选择的过程
工厂模式的使用，实际上是客户（产品的消费者）对于产品选择的过程，对于实现了相同功能的产品来讲，客户更加关心的是产品间的差异性，而工厂的作用则是将产品的生产过程封装，根据客户的要求直接返回客户需要的产品。注意，工厂只是隐藏了产品的生产过程，但是并没有剥夺客户选择的权利，那么客户的这个选择过程又是如何体现的呢？在简单工厂中，客户通过参数的形式告诉工厂需要什么样的产品，而在工厂方法中，客户通过对工厂的选择代替了直接对产品的选择，注意到工厂方法中一个工厂只有一个Create方法，也就是说一个工厂只负责生产一种产品，那么你选择了相应的工厂也就等同于你选择了对应的产品。就连改良后的反射工厂也没有消去对产品的选择，只不过是将这种选择外化（外化到配置文件中，从而使得对代码的改动最小）。可以说，正是由于产品间的差异性带给了客户选择的权利，这种权利是不应当被工厂取代的，那么工厂模式的价值又在哪里呢？答案是抽象与封装，工厂模式将由于客户的不同选择而可能导致的对已知事物的影响降到最低，途径是通过抽象产品取代具体产品，使得客户依赖于抽象（越抽象的东西越稳定），同时将客户的选择封装到一处，隔离与具体产品间的依赖。
工厂模式与抽象工厂
前面说了这么多无关的，为得是做好铺垫，更加有益于对下文的理解，OK，终于该说说从工厂模式到抽象工厂的转变了，先来对比两张类图：
工厂方法(Factory Method)
抽象工厂(Abstract Factory)
从图中我们能够看到哪些差异？
最明显的一点就是在工厂方法的类关系图中只有一类产品，他们实现了一个统一的接口，而抽象工厂有多个类别的产品，他们分别实现了不同的功能（多个接口）。其次的一点差别就是工厂本身所具有的方法数量不同，这点差异其实也是由第一点所导致的，工厂需要有生产不同类别产品的功能，如果抽象工厂中的产品的功能简化到一个，也便成为了工厂方法。
引出类别的概念，类别是指具有相同功能的一类产品的总称。
再来看选择的过程，在工厂方法中，客户关心的只不过是实现同一样功能的不同产品间的差异，这是一个一维选择的过程。
2 IProduct productA = factory.Create(); //工厂只有一个Create方法，只能生产一种产品
而在抽象工厂中，客户首先要考虑的是需要哪一样功能，其次要考虑才是产品间的差异。也就是说这是一个二维选择的过程。
2 IProduct productA = factory.CreateProductA(); //工厂具有多个Create方法，这里选择了其中的一个
由于产品类别的增加而导致客户在考虑产品间差异的同时还要考虑产品间功能的差异，这种二维选择的过程才是工厂方法与抽象工厂之间的本质区别。
举个肯德基与麦当劳的例子，假设原来只有一家快餐店叫做麦当劳，提供的食物（具体产品）有汉堡、可乐、薯条，它们都可以满足你吃东西（抽象接口）的需求，那么你想吃快餐的时候，唯一的选择就在于吃什么，是一维选择，现在又开了一家快餐店叫做肯德基，同样供应汉堡、可乐和薯条，那么现在你若打算吃快餐，除了考虑吃什么外，还要考虑去哪里吃--肯德基还是麦当劳？这便是二维的选择。通过横向与纵向的选择才能最终锁定你要的产品。 
引入系列的概念，相互间具有差异的同一类别的产品称为不同的系列，如肯德基和麦当劳就是两个不同的系列。
这种选择的区别带来的另外一个后果就是产品间的差异（系列间的差异）变为客户的次要选择，而客户主要的精力放在了功能的选择上（类别的选择）。
我们结合实例来看看抽象工厂的一般设计及实现
客户调用代码
2 IHamburger hamburger = factory.CreateHamburger(); //选择吃汉堡
可以看到系列间的选择由工厂的选择来替代，而类别间的选择实际上就是工厂内不同类别产品创建方法的选择。那么如此这般设计是否有依据呢？我们为什么不将工厂设计成为汉堡工厂，可乐工厂和薯条工厂呢？这其实是刚接触抽象工厂的人经常陷入的误区，这个问题的关键在于需求！需求是来自于客户的，工厂的设计取决于客户怎样使用产品。在这个例子中，之所以要将汉堡、可乐和薯条设计为类别而不是系列，首先是因为他们对于客户有不同的功能，例如汉堡可以充饥，薯条可以解馋、可乐可以解渴，任何一个客户希望走进一家店（无论是肯德基还是麦当劳）都能够得到上面的这三种功能，这才是客户真正的需求！如果客户选择走进了麦当劳，那么他就永远不会吃到肯德基的食品。这里有点绕可能需要多想一下，再举个例子帮助理解，比如星际争霸游戏，里面有三个种族，每个种族的兵营都能生产三种兵，如何选定类别与系列？抛开游戏的设计来讲，从用户的角度出发，我们还是会把系列对应成种族，那是因为任何一个玩家进入游戏后，都希望能够体验三个不同的兵种所具有的不同能力，而不是希望拥有一个能够制造出所有三个种族一级兵的兵营。反过来讲，用户每次进入游戏只可能选择一个种族，如果他这次选择了虫族，那么他就永远不可能生产出机枪兵。
最后再将上面提到的种种概念进行一下总结
类别 = 接口 = 抽象产品 = 具体产品所具有的共同功能，通过采用工厂的某个具体方法来体现选择。
系列 = 抽象工厂 = 同一类别间不同产品的差异，通过对实例化某个具体工厂来体现选择。
反射机制实现选择逻辑，关于工厂的工厂
有人的地方就有恩怨，有恩怨的地方就有江湖，人就是江湖，你怎么退出？
有选择的地方就有工厂，由工厂的地方就有反射，选择就是反射，你怎么设计？
呵呵… 开个玩笑，其实上面所写的几段废话就是为了论证这一个观点，有选择的地方就可以反射。看看我是如何把工厂方法改良成反射工厂的，既然工厂方法是一维的选择可以反射，那么对于抽象工厂这个二维的选择自然更不在话下，仔细观察工厂的选择过程。
2 IHamburger hamburger = factory.CreateHamburger(); //选择吃汉堡
发现选择分别是针对工厂的选择以及方法的选择，然而对于工厂内部方法的选择不适用于反射机制，因为不同的方法实现了不同的功能，相互间没有统一的接口，何谈反射，那么反射自然就只能放在对于工厂的选择上--它们都继承自抽象工厂。于是我们建立一个反射工厂用来动态生成需要的具体工厂，即工厂的工厂。话说起来别扭，还是看图。
这里新添加的FFactory就是反射工厂 ，对于反射工厂来说，Abstract Factory就是抽象产品，FactoryA和FactoryB是相应的具体产品。
2 <add key="factoryName" value="FactoryA"/>
3 </appSettings>
反射工厂
2 {
3 //从配置文件中读取需要实例化的工厂
4 string factoryName = ConfigurationSettings.AppSettings["factoryName"].ToString();
5
6 AbstractFactory factory;
7 factory = (AbstractFactory)Assembly.Load("Abstract Factory").CreateInstance("Abstract_Factory.ImproveFactory." + factoryName);
8 return factory;
9 }
客户使用
2 {
3 AbstractFactory factory = FFactory.CreateFactory();//生产工厂的工厂，采用反射机制
4 IProduct1 product1 = factory.CreateProduct1();
5 IProduct2 product2 = factory.CreateProduct2();
6
7 product1.DoTask1();
8 product2.DoTask2();
9 }
补充
抽象工厂的使用除了对多系列多类别的应用外，还有一点很重要的原则，即它的一系列的产品总是在一起使用的，只有这样才更能体现出抽象工厂的价值，关于这点我会在下一篇中通过与Builder模式作对比来阐述两者间的相同与异同。
