C23种设计模式 第2章 抽象工厂模式(Abstract Factory)(2)

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

1using System;

2

3namespace FactorySalary

4

5{ /// <summary>

6 /// Factory类

7 /// </summary>

8 public class Factory

9 {

10 public Tax CreateTax()

11 {

12 return new ChineseTax();

C#23种设计模式

13 } 14

15 public Bonus CreateBonus()

16 {

17 return new ChineseBonus();

18 }

19 }

20}

21

修改后的客户端代码：

1

2using System;

3

4namespace FactorySalary

5

6{ /// <summary>

7 /// 客户端程序调用

8 /// </summary>

9 public class Calculator

10 {

11 public static void Main(string[] args)

12 {

C#23种设计模式

13 Bonus bonus = new

Factory().CreateBonus();

14 double bonusValue = bonus.Calculate();

15

16 Tax tax = new Factory().CreateTax();

17 double taxValue = tax.Calculate();

18

19 double salary = 4000 + bonusValue - taxValue;

20

21 Console.WriteLine("Chinaese Salary is：" + salary);

22 Console.ReadLine();

23 }

24 }

25}

26

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

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

2

3namespace FactorySalary

4

5{ /// <summary>

C#23种设计模式

6 /// Factory类

7 /// </summary>

8 public class Factory

9 {

10 public Tax CreateTax()

11 {

12 return new AmericanTax();

13 }

14

15 public Bonus CreateBonus()

16 {

17 return new AmericanBonus();

18 }

19 }

20}

21

为系统增加抽象工厂方法

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

C#23种设计模式

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

抽象工厂类的代码如下：

1using System;

2using System.Reflection;

3

4namespace AbstractFactory

5{

C#23种设计模式

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();

C#23种设计模式

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接口。

C#23种设计模式

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();