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

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

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

　　 模型图

　　逻辑模型：

　　物理模型：

　　生活中的例子

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

　　 抽象工厂之新解

　　 虚拟案例

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

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

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

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

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

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

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

　　 案例分析

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

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

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

　　 针对中国企业为系统建模

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

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

1using System;
2
3namespace ChineseSalary
4{
5 /**//// ＜summary>
6 /// 公用的常量
7 /// ＜/summary>
8 public class Constant
9 {
10 public static double BASE_SALARY = 4000;
11 }
12}
1using System;
2
3namespace ChineseSalary
4{
5 /**//// ＜summary>
6 /// 计算中国个人奖金
7 /// ＜/summary>
8 public class ChineseBonus
9 {
10 public double Calculate()
11 {
12 return Constant.BASE_SALARY * 0.1;
13 }
14 }
15}
16

　　客户端的调用代码：

1using System;
2
3namespace ChineseSalary
4{
5 /**//// ＜summary>
6 /// 计算中国个人所得税
7 /// ＜/summary>
8 public class ChineseTax
9 {
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;
2
3namespace AmericanSalary
4{
5 /**//// ＜summary>
6 /// 公用的常量
7 /// ＜/summary>
8 public class Constant
9 {
10 public static double BASE_SALARY = 4000;
11 }
12}
13


1using System;
2
3namespace AmericanSalary
4{
5 /**//// ＜summary>
6 /// 计算美国个人奖金
7 /// ＜/summary>
8 public class AmericanBonus
9 {
10 public double Calculate()
11 {
12 return Constant.BASE_SALARY * 0.1;
13 }
14 }
15}
16

1using System;
2
3namespace AmericanSalary
4{
5 /**//// ＜summary>
6 /// 计算美国个人所得税
7 /// ＜/summary>
8 public class AmericanTax
9 {
10 public double Calculate()
11 {
12 return (Constant.BASE_SALARY + (Constant.BASE_SALARY * 0.1)) * 0.4;
13 }
14 }
15}
16

　　客户端的调用代码：

1
2using System;
3
4namespace AmericanSalary
5{
6 /**//// ＜summary>
7 /// 客户端程序调用
8 /// ＜/summary>
9 public class Calculator
10 {
11 public static void Main(string[] args)
12 {
13 AmericanBonus bonus = new AmericanBonus();
14 double bonusValue = bonus.Calculate();
15
16 AmericanTax tax = new AmericanTax();
17 double taxValue = tax.Calculate();
18
19 double salary = 4000 + bonusValue - taxValue;
20
21 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类即可。
本文转自
about:blank