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

2007-9-20　网友评论 0 条　点击进入论坛

　　1using System;

　　3namespace AmericanSalary

　　5 /**////

　　6 /// 计算美国个人所得税

　　7 ///

　　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}

　　客户端的调用代码：

　　2using System;

　　4namespace AmericanSalary

　　6 /**////

　　7 /// 客户端程序调用

　　8 ///

　　9 public class Calculator

　　10 {

　　11 public static void Main(string[] args)

　　12 {

　　13 AmericanBonus bonus = new AmericanBonus();

　　14 double bonusValue = bonus.Calculate();

　　16 AmericanTax tax = new AmericanTax();

　　17 double taxValue = tax.Calculate();

　　19 double salary = 4000 + bonusValue - taxValue;

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

　　22 Console.ReadLine();

　　23 }

　　24 }

　　25}

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

　　American Salary is：2640

　　整合成通用系统

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

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

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

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

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

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

　　让移植工作更简单

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

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

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

已有 0 位对此文章感兴趣的网友发布了看法　

我来评两句	登录邮箱：密码：
请您在这里发表您的个人看法，发言时请各位遵纪守法并注意语言文明！
	匿名发表

今日推荐

技术文库(共有 46468 篇文章)

产品技术答疑

重点推荐