抽象工厂--模式设计.docVIP

概述 　　在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。怎么应对这种变化？怎么绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程式和这种“多系列具体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。　　　意图　　提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。　　模型图　　逻辑模型： 　　物理模型： 　　生活中的例子　　抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不必指定他们具体的类。这种模式能汽车制造厂所使用的金属冲压设备中找到。这种冲压设备能制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改动冲压盘，这个机械产生的具体类能在三分钟内改动。 　　抽象工厂之新解　　虚拟案例　　中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。　　员工的工资 = (基本工资 + 奖金 - 个人所得税)。这是个放之四海皆准的运算法则。　　为了简化系统，我们假设员工基本工资总是4000美金。　　中国企业奖金和个人所得税的计算规则是:　　奖金 = 基本工资(4000) * 10%　　个人所得税 = (基本工资 + 奖金) * 40%　　我们目前要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。　　案例分析　　奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)。　　工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。　　工资的计算作为业务规则的前端(或客户端Client)将提供给最终使用该系统的用户(财务人员)使用。　　针对中国企业为系统建模　　根据上面的分析，为Softo系统建模如下： 　　则业务规则Service类的代码如下： 1using System;23namespace ChineseSalary4{5 /**//// ＜summary6 /// 公用的常量7 /// ＜/summary8 public class Constant9 {10 public static double BASE_SALARY = 4000;11 }12}1using System;23namespace ChineseSalary4{5 /**//// ＜summary6 /// 计算中国个人奖金7 /// ＜/summary8 public class ChineseBonus9 {10 public double Calculate()11 {12 return Constant.BASE_SALARY * 0.1;13 }14 }15}16 　　客户端的调用代码： 1using System;23namespace ChineseSalary4{ 5 /**//// ＜summary6 /// 计算中国个人所得税7 /// ＜/summary8 public class ChineseTax9 {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;23namespace AmericanSalary4{5 /**//// ＜summary6 /// 公用的常量7 /// ＜/summary8 public class Constant9 {10 public static do