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

【 tulaoshi.com - 编程语言 】

　　概述

　　在软件系统中，经常面临着一系列相互依赖的对象的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种封装机制来避免客户程序和这种多系列具体对象创建工作的紧耦合？这就是我们要说的抽象工厂模式。

　　意图

　　提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

　　模型图

　　逻辑模型：

　　物理模型：

　　生活中的例子

　　抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。这种模式可以汽车制造厂所使用的金属冲压设备中找到。这种冲压设备可以制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改变冲压盘，这个机械产生的具体类可以在三分钟内改变。

　　抽象工厂之新解

　　虚拟案例

　　中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。

　　员工的工资 = (基本工资 + 奖金 - 个人所得税)。这是一个放之四海皆准的运算法则。

　　为了简化系统，我们假设员工基本工资总是4000美金。

　　中国企业奖金和个人所得税的计算规则是:

　　奖金 = 基本工资(4000) * 10%

　　个人所得税 = (基本工资 + 奖金) * 40%

　　我们现在要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。

　　案例分析

　　奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)。

　　工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。

　　工资的计算作为业务规则的前端(或者客户端Client)将提供给最终使用该系统的用户(财务人员)使用。

　　针对中国企业为系统建模

　　根据上面的分析，为Softo系统建模如下：

　　则业务规则Service类的代码如下：

1using System;23namespace ChineseSalary4{5 /**//// ＜summary6 /// 公用的常量7 /// ＜/summary8 public class Constant9 {10 public static double BASE_SALARY = 4000;11 }12}1using System;23namespace ChineseSalary4{5 /**//// ＜summary6 /// 计算中国个人奖金7 /// ＜/summary8 public class ChineseBonus9 {10 public double Calculate()11 {12 return Constant.BASE_SALARY * 0.1;13 }14 }15}16

　　客户端的调用代码：

1using System;23namespace ChineseSalary4{5 /**//// ＜summary6 /// 计算中国个人所得税7 /// ＜/summary8 public class ChineseTax9 {10 public double Calculate()11 {12 return (Constant.BASE_SALARY + (Constant.BASE_SALARY * 0.1)) * 0.4;13 }14 }15}16

　　运行程序，输入的结果如下：

　　Chinese Salary is：2640

　　针对美国企业为系统建模

　　为了拓展国际市场，我们要把该系统移植给美国公司使用。 美国企业的工资计算同样是: 员工的工资 = 基本工资 + 奖金 - 个人所得税。

　　但是他们的奖金和个人所得税的计算规则不同于中国企业:

　　美国企业奖金和个人所得税的计算规则是:

　　奖金 = 基本工资 * 15 %

　　个人所得税 = (基本工资 * 5% + 奖金 * 25%)

　　根据前面为中国企业建模经验，我们仅仅将ChineseTax、ChineseBonus修改为AmericanTax、AmericanBonus。 修改后的模型如下：

　　则业务规则Service类的代码如下：

1using System;23namespace AmericanSalary4{5 /**//// ＜summary6 /// 公用的常量7 /// ＜/summary8 public class Constant9 {10 public static double BASE_SALARY = 4000;11 }12}131using System;23namespace AmericanSalary4{5 /**//// ＜summary6 /// 计算美国个人奖金7 /// ＜/summary8 public class AmericanBonus9 {10 public double Calculate()11 {12 return Constant.BASE_SALARY * 0.1;13 }14 }15}161using System;23namespace AmericanSalary4{5 /**//// ＜summary6 /// 计算美国个人所得税7 /// ＜/summary8 public class AmericanTax9 {10 public double Calculate()11 {12 return (Constant.BASE_SALARY + (Constant.BASE_SALARY * 0.1)) * 0.4;13 }14 }15}16

　　客户端的调用代码：

12using System;34namespace AmericanSalary5{6 /**//// ＜summary7 /// 客户端程序调用8 /// ＜/summary9 public class Calculator10 {11 public static void Main(string[] args)12 {13 AmericanBonus bonus = new AmericanBonus();14 double bonusValue = bonus.Calculate();1516 AmericanTax tax = new AmericanTax();17 double taxValue = tax.Calculate();1819 double salary = 4000 + bonusValue - taxValue;2021 Console.WriteLine("American Salary is：" + salary);22 Console.ReadLine();23 }24 }25}26

　　运行程序，输入的结果如下：

　　American Salary is：2640

　　整合成通用系统

　　让我们回顾一下该系统的发展历程：

　　最初，我们只考虑将Softo系统运行于中国企业。但随着MaxDO公司业务向海外拓展， MaxDO需要将该系统移植给美国使用。

　　移植时，MaxDO不得不抛弃中国企业的业务规则类ChineseTax和ChineseBonus， 然后为美国企业新建两个业务规则类: AmericanTax,AmericanBonus。最后修改了业务规则调用Calculator类。

　　结果我们发现：每当Softo系统移植的时候，就抛弃原来的类。现在，如果中国联想集团要购买该系统，我们不得不再次抛弃AmericanTax,AmericanBonus，修改回原来的业务规则。

　　一个可以立即想到的做法就是在系统中保留所有业务规则模型，即保留中国和美国企业工资运算规则。

　　通过保留中国企业和美国企业的业务规则模型，如果该系统在美国企业和中国企业之间切换时，我们仅仅需要修改Caculator类即可。

　　让移植工作更简单

　　前面系统的整合问题在于：当系统在客户在美国和中国企业间切换时仍然需要修改Caculator代码。

　　一个维护性良好的系统应该遵循开闭原则。即：封闭对原来代码的修改，开放对原来代码的扩展（如类的继承，接口的实现）

　　我们发现不论是中国企业还是美国企业，他们的业务运规则都采用同样的计算接口。 于是很自然地想到建立两个业务接口类Tax，Bonus，然后让AmericanTax、AmericanBonus和ChineseTax、ChineseBonus分别实现这两个接口， 据此修正后的模型如下：

　　此时客户端代码如下：

12using System;34namespace InterfaceSalary5{6 /**//// ＜summary7 /// 客户端程序调用8 /// ＜/summary9 public class Calculator10 {11 public static void Main(string[] args)12 {13 Bonus bonus = new ChineseBonus();14 double bonusValue = bonus.Calculate();1516 Tax tax = new ChineseTax();17 double taxValue = tax.Calculate();1819 double salary = 4000 + bonusValue - taxValue;2021 Console.WriteLine("Chinaese Salary is：" + salary);22 Console.ReadLine();23 }24 }25}26

　　为业务规则增加工厂方法

　　然而，上面增加的接口几乎没有解决任何问题，因为当系统的客户在美国和中国企业间切换时Caculator代码仍然需要修改。

　　只不过修改少了两处，但是仍然需要修改ChineseBonus,ChineseTax部分。致命的问题是：我们需要将这个移植工作转包给一个叫Hippo的软件公司。 由于版权问题，我们并未提供Softo系统的源码给Hippo公司，因此Hippo公司根本无法修改Calculator，导致实际上移植工作无法进行。

　　为此，我们考虑增加一个工具类(命名为Factory)，代码如下：

1using System;23namespace FactorySalary4{5 /**//// ＜summary6 /// Factory类7 /// ＜/summary8 public class Factory9 {10 public Tax CreateTax()11 {12 return new ChineseTax();13 }1415 public Bonus CreateBonus()16 {17 return new ChineseBonus();18 }19 }20}21

　　修改后的客户端代码：

12using System;34namespace FactorySalary5{6 /**//// ＜summary7 /// 客户端程序调用8 /// ＜/summary9 public class Calculator10 {11 public static void Main(string[] args)12 {13 Bonus bonus = new Factory().CreateBonus();14 double bonusValue = bonus.Calculate();1516 Tax tax = new Factory().CreateTax();17 double taxValue = tax.Calculate();1819 double salary = 4000 + bonusValue - taxValue;2021 Console.WriteLine("Chinaese Salary is：" + salary);22 Console.ReadLine();23 }24 }25}26

　　不错，我们解决了一个大问题，设想一下：当该系统从中国企业移植到美国企业时，我们现在需要做什么？

　　答案是: 对于Caculator类我们什么也不用做。我们需要做的是修改Factory类，修改结果如下：

1using System;23namespace FactorySalary4{5 /**//// ＜summary6 /// Factory类7 /// ＜/summary8 public class Factory9 {10 public Tax CreateTax()11 {12 return new AmericanTax();13 }1415 public Bonus CreateBonus()16 {17 return new AmericanBonus();18 }19 }20}21

　　为系统增加抽象工厂方法

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

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

　　抽象工厂类的代码如下：

1using System;2using System.Reflection;34namespace AbstractFactory5{6 /**//// ＜summary7 /// AbstractFactory类8 /// ＜/summary9 public abstract class AbstractFactory10 {11 public static AbstractFactory GetInstance()12 {13 string factoryName = Constant.STR_FACTORYNAME.ToString();1415 AbstractFactory instance;1617 if(factoryName == "ChineseFactory")18 instance = new ChineseFactory();19 else if(factoryName == "AmericanFactory")20 instance = new AmericanFactory();21 else22 instance = null;2324 return instance;25 }2627 public abstract Tax CreateTax();2829 public abstract Bonus CreateBonus();30 }31}

　　配置文件：

1＜？xml version="1.0" encoding="utf-8" ？2＜configuration3 ＜appSettings4 ＜add key="factoryName" value="AmericanFactory"＜/add5 ＜/appSettings6＜/configuration7

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

　　答案是: 我们仅仅需要修改配置文件，将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;34namespace AbstractFactory5{6 /**//// ＜summary7 /// AbstractFactory类8 /// ＜/summary9 public abstract class AbstractFactory10 {11 public static AbstractFactory GetInstance()12 {13 string factoryName = Constant.STR_FACTORYNAME.ToString();1415 AbstractFactory instance;1617 if(factoryName != "")18 instance = (AbstractFactory)Assembly.Load(factoryName).CreateInstance(factoryName);19 else20 instance = null;2122 return instance;23 }2425 public abstract Tax CreateTax();2627 public abstract Bonus CreateBonus();28 }29}30