快捷搜索:

.NET设计模式:抽象工厂模式(Abstract Factory)

设置设置设备摆设摆设文件:

1

2

3

4

5

6

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/**////

7/// AbstractFactory类

8///

9public abstract class AbstractFactory

10{

11public static AbstractFactory GetInstance()

12{

13string factoryName = Constant.STR_FACTORYNAME.ToString();

14

15AbstractFactory instance;

16

17if(factoryName != "")

抽象工厂之新解

虚拟案例

中国企业必要一项简单的财务谋略:每月月尾,财务职员要谋略员工的人为。

员工的人为 = (基础人为 + 奖金 - 小我所得税)。这是一个放之四海皆准的运算轨则。

为了简化系统,我们假设员工基础人为老是4000美金。

中国企业奖金和小我所得税的谋略规则是:

奖金 = 基础人为(4000) * 10%

小我所得税 = (基础人为 + 奖金) * 40%

我们现在要为此构建一个软件系统(代号叫Softo),满意中国企业的需求。

案例阐发

奖金(Bonus)、小我所得税(Tax)的谋略是Softo系统的营业规则(Service)。

人为的谋略(Calculator)则调用营业规则(Service)来谋略员工的实际人为。

人为的盘看成为营业规则的前端(或者客户端Client)将供给给终极应用该系统的用户(财务职员)应用。

针对中国企业为系统建模

根据上面的阐发,为Softo系统建模如下:

则营业规则Service类的代码如下:

1using System;

2

3namespace ChineseSalary

4{

5/**////

6/// 公用的常量

7///

8public class Constant

9{

10public static double BASE_SALARY = 4000;

11}

12}

1using System;

2

3namespace ChineseSalary

4{

5/**////

6/// 谋略中国小我奖金

7///

8public class ChineseBonus

9{

10public double Calculate()

11{

12return Constant.BASE_SALARY * 0.1;

13}

14}

15}

16

客户真个调用代码:

1using System;

2

3namespace ChineseSalary

4{

5/**////

6/// 谋略中国小我所得税

7///

8public class ChineseTax

9{

10public double Calculate()

11{

12return (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/**////

6/// 公用的常量

7///

8public class Constant

9{

10public static double BASE_SALARY = 4000;

11}

12}

13

1using System;

2

3namespace AmericanSalary

4{

5/**////

6/// 谋略美国小我奖金

7///

8public class AmericanBonus

9{

10public double Calculate()

11{

12return Constant.BASE_SALARY * 0.1;

13}

14}

15}

16

1using System;

2

3namespace AmericanSalary

4{

5/**////

6/// 谋略美国小我所得税

7///

8public class AmericanTax

9{

10public double Calculate()

11{

12return (Constant.BASE_SALARY + (Constant.BASE_SALARY * 0.1)) * 0.4;

13}

14}

15}

16

客户真个调用代码:

1

2using System;

3

4namespace AmericanSalary

5{

6/**////

7/// 客户端法度榜样调用

8///

9public class Calculator

10{

11public static void Main(string[] args)

12{

13AmericanBonus bonus = new AmericanBonus();

14double bonusValue= bonus.Calculate();

15

16AmericanTax tax = new AmericanTax();

17double taxValue = tax.Calculate();

18

19double salary = 4000 + bonusValue - taxValue;

20

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

22Console.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分手实现这两个接口, 据此修正后的模型如下:

您可能还会对下面的文章感兴趣: