C＃设计模式编程之抽象工厂模式新解

为系统增加抽象工厂方法

　　很显然，前面的解决方案带来了一个副作用：就是系统不但增加了新的类Factory，而且当系统移植时，移植工作仅仅是转移到Factory类上，工作量并没有任何缩减，而且还是要修改系统的源码。 从Factory类在系统移植时修改的内容我们可以看出: 实际上它是专属于美国企业或者中国企业的。名称上应该叫AmericanFactory,ChineseFactory更合适.

　　解决方案是增加一个抽象工厂类AbstractFactory，增加一个静态方法，该方法根据一个配置文件(App.config或者Web.config) 一个项(比如factoryName)动态地判断应该实例化哪个工厂类，这样，我们就把移植工作转移到了对配置文件的修改。修改后的模型和代码：


　　抽象工厂类的代码如下：

1using System; 2using System.Reflection; 3 4namespace AbstractFactory 5{ 6 /**//// ＜summary> 7 /// AbstractFactory类 8 /// ＜/summary> 9 public abstract class AbstractFactory 10 { 11 public static AbstractFactory GetInstance() 12 { 13 string factoryName = Constant.STR_FACTORYNAME.ToString(); 14 15 AbstractFactory instance; 16 17 if(factoryName == "ChineseFactory") 18 instance = new ChineseFactory(); 19 else if(factoryName == "AmericanFactory") 20 instance = new AmericanFactory(); 21 else 22 instance = null; 23 24 return instance; 25 } 26 27 public abstract Tax CreateTax(); 28 29 public abstract Bonus CreateBonus(); 30 } 31}

　　配置文件：

1＜?xml version="1.0" encoding="utf-8" ?> 2＜configuration> 3 ＜appSettings> 4 ＜add key="factoryName" value="AmericanFactory">＜/add> 5 ＜/appSettings> 6＜/configuration> 7

　　采用上面的解决方案，当系统在美国企业和中国企业之间切换时，我们需要做什么移植工作？

　　答案是: 我们仅仅需要修改配置文件，将factoryName的值改为American。

　　修改配置文件的工作很简单，只要写一篇幅配置文档说明书提供给移植该系统的团队(比如Hippo公司) 就可以方便地切换使该系统运行在美国或中国企业。

　　最后的修正（不是最终方案）

　　前面的解决方案几乎很完美，但是还有一点瑕疵，瑕疵虽小，但可能是致命的。
　　
　　考虑一下，现在日本NEC公司决定购买该系统，NEC公司的工资的运算规则遵守的是日本的法律。如果采用上面的系统构架，这个移植我们要做哪些工作呢?

　　1. 增加新的业务规则类JapaneseTax,JapaneseBonus分别实现Tax和Bonus接口。

　　2. 修改AbstractFactory的getInstance方法，增加else if(factoryName.equals("Japanese")){....

　　注意: 系统中增加业务规则类不是模式所能解决的，无论采用什么设计模式，JapaneseTax,JapaneseBonus总是少不了的。（即增加了新系列产品）

　　我们真正不能接受的是：我们仍然修要修改系统中原来的类(AbstractFactory)。前面提到过该系统的移植工作，我们可能转包给一个叫Hippo的软件公司。 为了维护版权，未将该系统的源码提供给Hippo公司，那么Hippo公司根本无法修改AbstractFactory，所以系统移植其实无从谈起，或者说系统移植总要开发人员亲自参与。

　　解决方案是将抽象工厂类中的条件判断语句，用.NET中发射机制代替，修改如下：

1using System; 2using System.Reflection; 3 4namespace AbstractFactory 5{ 6 /**//// ＜summary> 7 /// AbstractFactory类 8 /// ＜/summary> 9 public abstract class AbstractFactory 10 { 11 public static AbstractFactory GetInstance() 12 { 13 string factoryName = Constant.STR_FACTORYNAME.ToString(); 14 15 AbstractFactory instance; 16 17 if(factoryName != "") 18 instance = (AbstractFactory)Assembly.Load(factoryName).CreateInstance(factoryName); 19 else 20 instance = null; 21 22 return instance; 23 } 24 25 public abstract Tax CreateTax(); 26 27 public abstract Bonus CreateBonus(); 28 } 29} 30

　　这样，在我们编写的代码中就不会出现Chinese，American，Japanese等这样的字眼了。

　　小结

　　最后那幅图是最终版的系统模型图。我们发现作为客户端角色的Calculator仅仅依赖抽象类， 它不必去理解中国和美国企业具体的业务规则如何实现，Calculator面对的仅仅是业务规则接口Tax和Bonus。

　　Softo系统的实际开发的分工可能是一个团队专门做业务规则，另一个团队专门做前端的业务规则组装。 抽象工厂模式有助于这样的团队的分工: 两个团队通讯的约定是业务接口，由抽象工厂作为纽带粘合业务规则和前段调用，大大降低了模块间的耦合性，提高了团队开发效率。

　　完完全全地理解抽象工厂模式的意义非常重大，可以说对它的理解是你对OOP理解上升到一个新的里程碑的重要标志。 学会了用抽象工厂模式编写框架类，你将理解OOP的精华:面向接口编程。

　　应对“新对象”

　　抽象工厂模式主要在于应对“新系列”的需求变化。其缺点在于难于应付“新对象”的需求变动。如果在开发中出现了新对象，该如何去解决呢？这个问题并没有一个好的答案，下面我们看一下李建忠老师的回答：

　　“GOF《设计模式》中提出过一种解决方法，即给创建对象的操作增加参数，但这种做法并不能令人满意。事实上，对于新系列加新对象，就我所知，目前还没有完美的做法，只有一些演化的思路，这种变化实在是太剧烈了，因为系统对于新的对象是完全陌生的。” 实现要点

　　·抽象工厂将产品对象的创建延迟到它的具体工厂的子类。

　　·如果没有应对“多系列对象创建”的需求变化，则没有必要使用抽象工厂模式，这时候使用简单的静态工厂完全可以。

　　·系列对象指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。

　　·抽象工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化。

　　·通常在运行时刻创建一个具体工厂类的实例，这一具体工厂的创建具有特定实现的产品对象，为创建不同的产品对象，客户应使用不同的具体工厂。 l 把工厂作为单件，一个应用中一般每个产品系列只需一个具体工厂的实例，因此，工厂通常最好实现为一个单件模式。

　　·创建产品，抽象工厂仅声明一个创建产品的接口，真正创建产品是由具体产品类创建的，最通常的一个办法是为每一个产品定义一个工厂方法，一个具体的工厂将为每个产品重定义该工厂方法以指定产品，虽然这样的实现很简单，但它确要求每个产品系列都要有一个新的具体工厂子类，即使这些产品系列的差别很小。 优点

　　·分离了具体的类。抽象工厂模式帮助你控制一个应用创建的对象的类，因为一个工厂封装创建产品对象的责任和过程。它将客户和类的实现分离，客户通过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，它们不出现在客户代码中。

　　·它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。

　　·它有利于产品的一致性。当一个系列的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要，而抽象工厂很容易实现这一点。

　　缺点

　　·难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。

　　适用性

　　在以下情况下应当考虑使用抽象工厂模式：

　　·一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。

　　·这个系统有多于一个的产品族，而系统只消费其中某一产品族。

　　·同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。

　　·系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。

　　应用场景

　　·支持多种观感标准的用户界面工具箱（Kit）。

　　·游戏开发中的多风格系列场景，比如道路，房屋，管道等。

　　·……

　　总结

　　总之，抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，运用抽象工厂模式的关键点在于应对“多系列对象创建”的需求变化。一句话，学会了抽象工厂模式，你将理解OOP的精华：面向接口编程。

查看本文来源