《2022年抽象工厂--模式设计 .pdf》由会员分享，可在线阅读，更多相关《2022年抽象工厂--模式设计 .pdf（16页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、概述在软件系统中，经常面临着“ 一系列相互依赖的对象” 的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。怎么应对这种变化？怎么绕过常规的对象的创建方法（new），提供一种 “ 封装机制 ” 来避免客户程式和这种“ 多系列具体对象创建工作 ” 的紧耦合？这就是我们要说的抽象工厂模式。意图提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。模型图逻辑模型：物理模型：生活中的例子抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不必指定他们具体的类。这种模式能汽车制造厂所名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - -
2、- - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 16 页 - - - - - - - - - 使用的金属冲压设备中找到。这种冲压设备能制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改动冲压盘，这个机械产生的具体类能在三分钟内改动。抽象工厂之新解虚拟案例中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。员工的工资= (基本工资+ 奖金- 个人所得税 )。这是个放之四海皆准的运算法则。为了简化系统，我们假设员工基本工资总是4000 美金。中国企业奖金和个人所得税的计算
3、规则是: 奖金 = 基本工资 (4000) * 10% 个人所得税= (基本工资+ 奖金) * 40% 我们目前要为此构建一个软件系统（代号叫Softo ），满足中国企业的需求。案例分析奖金(Bonus) 、个人所得税 (Tax) 的计算是 Softo 系统的业务规则 (Service) 。工资的计算 (Calculator) 则调用业务规则 (Service) 来计算员工的实际工资。工资的计算作为业务规则的前端(或客户端 Client) 将提供给最终使用该系统的用户(财务人员 )使用。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - -
4、 - 名师精心整理 - - - - - - - 第 2 页，共 16 页 - - - - - - - - - 针对中国企业为系统建模根据上面的分析，为Softo 系统建模如下：则业务规则Service 类的代码如下：1using System; 2 3namespace ChineseSalary 4 5 /*/ summary 6 / 公用的常量7 / /summary 8 public class Constant 9 10 public static double BASE_SALARY = 4000; 11 12 1using System; 2 3namespace ChineseS
5、alary 4 5 /*/ summary 6 / 计算中国个人奖金7 / /summary 8 public class ChineseBonus 9 10 public double Calculate() 11 12 return Constant.BASE_SALARY * 0.1; 13 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 16 页 - - - - - - - - - 14 15 16 客户端的调用代码：1using System; 2 3names
6、pace ChineseSalary 4 5 /*/ summary 6 / 计算中国个人所得税7 / /summary 8 public class ChineseTax 9 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 针对美国企业为系统建模为了拓展国际市场， 我们要把该系统移植给美国公司使用。美国企业的工资计算同样是: 员工的工资= 基本
7、工资+ 奖金 - 个人所得税。不过他们的奖金和个人所得税的计算规则不同于中国企业: 美国企业奖金和个人所得税的计算规则是: 奖金= 基本工资* 15 % 个人所得税= (基本工资* 5% + 奖金 * 25%) 根据前面为中国企业建模经验，我们仅仅将ChineseTax 、ChineseBonus修改为 AmericanTax 、AmericanBonus 。 修改后的模型如下：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 16 页 - - - - - - - - -
8、则业务规则Service 类的代码如下：1using System; 2 3namespace AmericanSalary 4 5 /*/ summary 6 / 公用的常量7 / /summary 8 public class Constant 9 10 public static double BASE_SALARY = 4000; 11 12 13 1using System; 2 3namespace AmericanSalary 4 5 /*/ summary 6 / 计算美国个人奖金7 / /summary 8 public class AmericanBonus 9 10 pu
9、blic double Calculate() 11 12 return Constant.BASE_SALARY * 0.1; 13 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 16 页 - - - - - - - - - 14 15 16 1using System; 2 3namespace AmericanSalary 4 5 /*/ summary 6 / 计算美国个人所得税7 / /summary 8 public class AmericanTax 9
10、10 public double Calculate() 11 12 return (Constant.BASE_SALARY + (Constant.BASE_SALARY * 0.1) * 0.4; 13 14 15 16 客户端的调用代码：1 2using System; 3 4namespace AmericanSalary 5 6 /*/ summary 7 / 客户端程式调用8 / /summary 9 public class Calculator 10 11 public static void Main(string args) 12 13 AmericanBonus bon
11、us = new AmericanBonus(); 14 double bonusValue = bonus.Calculate(); 15 16 AmericanTax tax = new AmericanTax(); 17 double taxValue = tax.Calculate(); 18 19 double salary = 4000 + bonusValue - taxValue; 20 21 Console.WriteLine(American Salary is： + salary); 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - -
12、 - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 16 页 - - - - - - - - - 22 Console.ReadLine(); 23 24 25 26 运行程式，输入的结果如下：American Salary is ：2640 整合成通用系统让我们回顾一下该系统的发展历程：最初，我们只考虑将Softo 系统运行于中国企业。但随着MaxDO 公司业务向海外拓展，MaxDO 需要将该系统移植给美国使用。移植时， MaxDO 不得不抛弃中国企业的业务规则类ChineseTax和 ChineseBonus ， 然后为美国企业新建两个业务规则类: Amer
13、icanTax,AmericanBonus。最后修改了业务规则调用Calculator 类。结果我们发现：每当Softo 系统移植的时候，就抛弃原来的类。目前，如果中国联想集团要购买该系统，我们不得不再次抛弃 AmericanTax,AmericanBonus，修改回原来的业务规则。一个能即时想到的做法就是在系统中保留所有业务规则模型，即保留中国和美国企业工资运算规则。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 16 页 - - - - - - - - - 通过保留中
14、国企业和美国企业的业务规则模型，如果该系统在美国企业和中国企业之间转换时，我们仅仅需要修改Caculator类即可。让移植工作更简单前面系统的整合问题在于：当系统在客户在美国和中国企业间转换时仍然需要修改Caculator 代码。一个维护性良好的系统应该遵循“ 开闭原则 ” 。即：封闭对原来代码的修改，开放对原来代码的扩展（如类的继承，接口的实现）我们发现不论是中国企业还是美国企业，他们的业务运规则都采用同样的计算接口。于是非常自然地想到建立两个业务接口类 Tax，Bonus ，然后让 AmericanTax 、AmericanBonus和 ChineseTax 、ChineseBonus分别
15、实现这两个接口，据此修正后的模型如下：此时客户端代码如下：1 2using System; 3 4namespace InterfaceSalary 5 6 /*/ summary 7 / 客户端程式调用8 / /summary 9 public class Calculator 10 11 public static void Main(string args) 12 13 Bonus bonus = new ChineseBonus(); 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - -
16、- 第 8 页，共 16 页 - - - - - - - - - 14 double bonusValue = bonus.Calculate(); 15 16 Tax tax = new ChineseTax(); 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 为业务规则增加工厂方法
17、然而，上面增加的接口几乎没有解决所有问题，因为当系统的客户在美国和中国企业间转换时Caculator 代码仍然需要修改。只不过修改少了两处，不过仍然需要修改ChineseBonus,ChineseTax部分。致命的问题是：我们需要将这个移植工作转包给一个叫 Hippo 的软件公司。由于版权问题，我们并未提供Softo 系统的源码给Hippo 公司，因此Hippo 公司根本无法修改Calculator ，导致实际上移植工作无法进行。为此，我们考虑增加一个工具类(命名为 Factory) ，代码如下：1using System; 2 3namespace FactorySalary 4 5 /*/
18、 summary 6 / Factory类7 / /summary 8 public class Factory 9 10 public Tax CreateTax() 11 12 return new ChineseTax(); 13 14 15 public Bonus CreateBonus() 16 17 return new ChineseBonus(); 18 19 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 16 页 - - - - - - - - -
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 13 Bonus bonus = new Factory().CreateBonus(); 14 double bonusValue = bonus.Calculate(); 15 16 Tax tax = new Factory().CreateTax(
20、); 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;
21、2 3namespace FactorySalary 4 5 /*/ summary 6 / Factory类7 / /summary 8 public class Factory 9 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 16 页 - - - - - - - - - 10 public Tax CreateTax() 11 12 return new AmericanTax(); 13 14 15 public Bonus CreateBonus() 16
22、17 return new AmericanBonus(); 18 19 20 21 为系统增加抽象工厂方法非常显然，前面的解决方案带来了一个副作用：就是系统不仅增加了新的类Factory ，而且当系统移植时，移植工作仅仅是转移到 Factory 类上，工作量并没有所有缩减，而且还是要修改系统的源码。从 Factory 类在系统移植时修改的内容我们能看出: 实际上他是专属于美国企业或中国企业的。名称上应该叫AmericanFactory,ChineseFactory更合适 . 解决方案是增加一个抽象工厂类AbstractFactory ，增加一个静态方法，该方法根据一个设置文件(App.con
23、fig或 Web.config) 一个项 (比如 factoryName) 动态地判断应该实例化哪个工厂类，这样，我们就把移植工作转移到了对设置文件的修改。修改后的模型和代码：抽象工厂类的代码如下：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 16 页 - - - - - - - - - 1using System; 2using System.Reflection; 3 4namespace AbstractFactory 5 6 /*/ summary 7 / A
24、bstractFactory类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(
25、factoryName = AmericanFactory) 20 instance = new AmericanFactory(); 21 else 22 instance = null; 23 24 return instance; 25 26 27 public abstract Tax CreateTax(); 28 29 public abstract Bonus CreateBonus(); 30 31 设置文件：1?xml version=1.0 encoding=utf-8 ? 2configuration 3 appSettings 4 add key=factoryName
26、 value=AmericanFactory/add 5 /appSettings 6/configuration 7 采用上面的解决方案，当系统在美国企业和中国企业之间转换时，我们需要做什么移植工作？名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 12 页，共 16 页 - - - - - - - - - 答案是 : 我们仅仅需要修改设置文件，将factoryName的值改为 American 。修改设置文件的工作非常简单，只要写一篇幅设置文件说明书提供给移植该系统的团队(比如 H
27、ippo 公司 ) 就能方便地转换使该系统运行在美国或中国企业。最后的修正（不是最终方案）前面的解决方案几乎非常完美，不过更有一点瑕疵，瑕疵虽小，但可能是致命的。考虑一下，目前日本NEC 公司决定购买该系统，NEC 公司的工资的运算规则遵守的是日本的法律。如果采用上面的系统构架，这个移植我们要做哪些工作呢? 1. 增加新的业务规则类JapaneseTax,JapaneseBonus分别实现 Tax 和 Bonus 接口。2. 修改 AbstractFactory的 getInstance 方法，增加else if(factoryName.equals(Japanese). 注意: 系统中增加业
28、务规则类不是模式所能解决的，无论采用什么设计模式，JapaneseTax,JapaneseBonus总是少不了的。（即增加了新系列产品）我们真正不能接受的是：我们仍然修要修改系统中原来的类(AbstractFactory) 。前面提到过该系统的移植工作，我们可能转包给一个叫Hippo 的软件公司。为了维护版权，未将该系统的源码提供给Hippo 公司，那么 Hippo 公司根本无法修改AbstractFactory ，所以系统移植其实无从谈起，或说系统移植总要研发人员亲自参和。解决方案是将抽象工厂类中的条件判断语句，用.NET 中发射机制代替，修改如下：1using System; 2using
29、 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(factory
30、Name != ) 18 instance = (AbstractFactory)Assembly.Load(factoryName).CreateInstance(factoryName); 19 else 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 13 页，共 16 页 - - - - - - - - - 20 instance = null; 21 22 return instance; 23 24 25 public abstract Tax CreateTax();
31、26 27 public abstract Bonus CreateBonus(); 28 29 30 这样，在我们编写的代码中就不会出现Chinese ，American ，Japanese 等这样的字眼了。小结最后那幅图是最终版的系统模型图。我们发现作为客户端角色的Calculator 仅仅依赖抽象类，他不必去理解中国和美国企业具体的业务规则怎么实现，Calculator 面对的仅仅是业务规则接口Tax 和 Bonus 。Softo 系统的实际研发的分工可能是个团队专门做业务规则，另一个团队专门做前端的业务规则组装。抽象工厂模式有助于这样的团队的分工: 两个团队通讯的约定是业务接口，由抽象
32、工厂作为纽带粘合业务规则和前段调用，大大降低了模块间的耦合性，提高了团队研发效率。完完全全地理解抽象工厂模式的意义非常重大，能说对他的理解是你对OOP 理解上升到一个新的里程碑的重要标志。学会了用抽象工厂模式编写框架类，你将理解OOP 的精华 :面向接口编程。应对 “ 新对象 ”抽象工厂模式主要在于应对“ 新系列 ” 的需求变化。其缺点在于难于应付“ 新对象 ” 的需求变动。如果在研发中出现了新对象，该怎么去解决呢？这个问题并没有一个好的答案，下面我们看一下李建忠老师的回答：“GOF 设计模式中提出过一种解决方法，即给创建对象的操作增加参数，但这种做法并不能令人满意。事实上，对于新系列加新对象
33、，就我所知，目前还没有完美的做法，只有一些演化的思路，这种变化实在是太剧烈了，因为系统对于新的对象是完全陌生的。 ” 实现要点?抽象工厂将产品对象的创建延迟到他的具体工厂的子类。?如果没有应对 “ 多系列对象创建 ” 的需求变化，则没有必要使用抽象工厂模式，这时候使用简单的静态工厂完万能。?系列对象指的是这些对象之间有相互依赖、或作用的关系，例如游戏研发场景中的“ 道路” 和“ 房屋 ” 的依赖， “ 道路” 和“ 地道”的依赖。?抽象工厂模式经常和工厂方法模式一起组合来应对“ 对象创建 ” 的需求变化。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - -
34、- - - - - - 名师精心整理 - - - - - - - 第 14 页，共 16 页 - - - - - - - - - ?通常在运行时刻创建一个具体工厂类的实例，这一具体工厂的创建具有特定实现的产品对象，为创建不同的产品对象，客户应使用不同的具体工厂。l 把工厂作为单件，一个应用中一般每个产品系列只需一个具体工厂的实例，因此，工厂通常最佳实现为一个单件模式。?创建产品，抽象工厂仅声明一个创建产品的接口，真正创建产品是由具体产品类创建的，最通常的一个办法是为每一个产品定义一个工厂方法，一个具体的工厂将为每个产品重定义该工厂方法以指定产品，虽然这样的实现非常简单，但他确需求每个产品系列都
35、要有一个新的具体工厂子类，即使这些产品系列的差别非常小。好处?分离了具体的类。抽象工厂模式帮助你控制一个应用创建的对象的类，因为一个工厂封装创建产品对象的责任和过程。他将客户和类的实现分离，客户通过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，他们不出目前客户代码中。?他使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次?即在他初始化的时候。这使得改动一个应用的具体工厂变得非常容易。他只需改动具体的工厂即可使用不同的产品设置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会即时改动。?他有利于产品的一致性。当一个系列的产品对象被设计成一起工作时，一个应用
36、一次只能使用同一个系列中的对象，这一点非常重要，而抽象工厂非常容易实现这一点。缺点?难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了能被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改动。适用性在以下情况下应当考虑使用抽象工厂模式：?一个系统不应当依赖于产品类实例怎么被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。?这个系统有多于一个的产品族，而系统只消费其中某一产品族。?同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。?系统提供一个产品类的库，所有的产品以同样的接口出现，从而
37、使客户端不依赖于实现。应用场景?支持多种观感标准的用户界面工具箱（Kit）。?游戏研发中的多风格系列场景，比如道路，房屋，管道等。?名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 15 页，共 16 页 - - - - - - - - - 总结总之，抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，运用抽象工厂模式的关键点在于应对“ 多系列对象创建” 的需求变化。一句话，学会了抽象工厂模式，你将理解OOP 的精华：面向接口编程。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 16 页，共 16 页 - - - - - - - - -