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 != "")
文章来源于领测软件测试网 https://www.ltesting.net/