?概述
在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。怎么应对这种变化？怎么绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程式和这种“多系列具体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。
意图
提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。
模型图
逻辑模型：
物理模型：
生活中的例子
抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不必指定他们具体的类。这种模式能汽车制造厂所
使用的金属冲压设备中找到。这种冲压设备能制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改动冲压盘，这个机械产生的具体类能在三分钟内改动。
抽象工厂之新解
虚拟案例
中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。
员工的工资= (基本工资+ 奖金- 个人所得税)。这是个放之四海皆准的运算法则。
为了简化系统，我们假设员工基本工资总是4000美金。
中国企业奖金和个人所得税的计算规则是:
奖金= 基本工资(4000) * 10%
个人所得税= (基本工资+ 奖金) * 40%
我们目前要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。
案例分析
奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)。
工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。
工资的计算作为业务规则的前端(或客户端Client)将提供给最终使用该系统的用户(财务人员)使用。
针对中国企业为系统建模
根据上面的分析，为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 ChineseSalary
4{
5 /**//// ＜summary>
6 /// 计算中国个人奖金
7 /// ＜/summary>
8 public class ChineseBonus
9 {
10 public double Calculate()
11 {
12 return Constant.BASE_SALARY * 0.1;
13 }
14 }
15}
16
客户端的调用代码：
1using System;
2
3namespace 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
针对美国企业为系统建模
为了拓展国际市场，我们要把该系统移植给美国公司使用。美国企业的工资计算同样是: 员工的工资= 基本工资+ 奖金-
个人所得税。
不过他们的奖金和个人所得税的计算规则不同于中国企业:
美国企业奖金和个人所得税的计算规则是:
奖金= 基本工资* 15 %
个人所得税= (基本工资* 5% + 奖金* 25%)
根据前面为中国企业建模经验，我们仅仅将ChineseTax、ChineseBonus修改为AmericanTax、AmericanBonus。修改后
的模型如下：
则业务规则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 public double Calculate()
11 {
12 return Constant.BASE_SALARY * 0.1;
13 }
14 }
15}
16
1using System;
2
3namespace AmericanSalary
4{
5 /**//// ＜summary>
6 /// 计算美国个人所得税
7 /// ＜/summary>
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}
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 bonus = 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);
22 Console.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分别实现这两个接口，据此修正后的模型如下：
此时客户端代码如下：
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();
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
为业务规则增加工厂方法
然而，上面增加的接口几乎没有解决所有问题，因为当系统的客户在美国和中国企业间转换时Caculator代码仍然需要修改。
只不过修改少了两处，不过仍然需要修改ChineseBonus,ChineseTax部分。致命的问题是：我们需要将这个移植工作转包给一个叫Hippo的软件公司。由于版权问题，我们并未提供Softo系统的源码给Hippo公司，因此Hippo公司根本无法修改
Calculator，导致实际上移植工作无法进行。
为此，我们考虑增加一个工具类(命名为Factory)，代码如下：
1using System;
2
3namespace FactorySalary
4{
5 /**//// ＜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 }
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();
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;
2
3namespace FactorySalary
4{
5 /**//// ＜summary>
6 /// Factory类
7 /// ＜/summary>
8 public class Factory
9 {
10 public Tax CreateTax()
11 {
12 return new AmericanTax();
13 }
14
15 public Bonus CreateBonus()
16 {
17 return new AmericanBonus();
18 }
19 }
20}
21
为系统增加抽象工厂方法
非常显然，前面的解决方案带来了一个副作用：就是系统不仅增加了新的类Factory，而且当系统移植时，移植工作仅仅是转移到Factory类上，工作量并没有所有缩减，而且还是要修改系统的源码。从Factory类在系统移植时修改的内容我们能看出: 实际上他是专属于美国企业或中国企业的。名称上应该叫AmericanFactory,ChineseFactory更合适.
解决方案是增加一个抽象工厂类AbstractFactory，增加一个静态方法，该方法根据一个设置文件(App.config或Web.config) 一个项(比如factoryName)动态地判断应该实例化哪个工厂类，这样，我们就把移植工作转移到了对设置文件的修改。修改后的
模型和代码：
抽象工厂类的代码如下：
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 == "ChineseFactory")
18 instance = new ChineseFactory();
19 else if(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" ?>
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 != "")
18 instance = (AbstractFactory)Assembly.Load(factoryName).CreateInstance(factoryName);
19 else
20 instance = null;
21
22 return instance;
23 }
24
25 public abstract Tax CreateTax();
26
27 public abstract Bonus CreateBonus();
28 }
29}
30
这样，在我们编写的代码中就不会出现Chinese，American，Japanese等这样的字眼了。
小结
最后那幅图是最终版的系统模型图。我们发现作为客户端角色的Calculator仅仅依赖抽象类，他不必去理解中国和美国企业具体的业务规则怎么实现，Calculator面对的仅仅是业务规则接口Tax和Bonus。
Softo系统的实际研发的分工可能是个团队专门做业务规则，另一个团队专门做前端的业务规则组装。抽象工厂模式有助于这样的团队的分工: 两个团队通讯的约定是业务接口，由抽象工厂作为纽带粘合业务规则和前段调用，大大降低了模块间的耦合
性，提高了团队研发效率。
完完全全地理解抽象工厂模式的意义非常重大，能说对他的理解是你对OOP理解上升到一个新的里程碑的重要标志。学会了用抽象工厂模式编写框架类，你将理解OOP的精华:面向接口编程。
应对“新对象”
抽象工厂模式主要在于应对“新系列”的需求变化。其缺点在于难于应付“新对象”的需求变动。如果在研发中出现了新对象，该怎么去解决呢？这个问题并没有一个好的答案，下面我们看一下李建忠老师的回答：
“GOF《设计模式》中提出过一种解决方法，即给创建对象的操作增加参数，但这种做法并不能令人满意。事实上，对于新系列加新对象，就我所知，目前还没有完美的做法，只有一些演化的思路，这种变化实在是太剧烈了，因为系统对于新的对象是完
全陌生的。” 实现要点
?抽象工厂将产品对象的创建延迟到他的具体工厂的子类。
?如果没有应对“多系列对象创建”的需求变化，则没有必要使用抽象工厂模式，这时候使用简单的静态工厂完万能。
?系列对象指的是这些对象之间有相互依赖、或作用的关系，例如游戏研发场景中的“道路”和“房屋”的依赖，“道路”和“地道”
的依赖。
?抽象工厂模式经常和工厂方法模式一起组合来应对“对象创建”的需求变化。
?通常在运行时刻创建一个具体工厂类的实例，这一具体工厂的创建具有特定实现的产品对象，为创建不同的产品对象，客户应使用不同的具体工厂。l 把工厂作为单件，一个应用中一般每个产品系列只需一个具体工厂的实例，因此，工厂通常最佳实
现为一个单件模式。
?创建产品，抽象工厂仅声明一个创建产品的接口，真正创建产品是由具体产品类创建的，最通常的一个办法是为每一个产品定义一个工厂方法，一个具体的工厂将为每个产品重定义该工厂方法以指定产品，虽然这样的实现非常简单，但他确需求每个产品系列都要有一个新的具体工厂子类，即使这些产品系列的差别非常小。好处
?分离了具体的类。抽象工厂模式帮助你控制一个应用创建的对象的类，因为一个工厂封装创建产品对象的责任和过程。他将客户和类的实现分离，客户通过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，他们不出目前客户代码
中。
?他使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次??即在他初始化的时候。这使得改动一个应用的具体工厂变得非常容易。他只需改动具体的工厂即可使用不同的产品设置，这是因为一个抽象工厂创建了一个完整的产品系列，所以
整个产品系列会即时改动。
?他有利于产品的一致性。当一个系列的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一
点非常重要，而抽象工厂非常容易实现这一点。
缺点
?难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了能被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改动。
适用性
在以下情况下应当考虑使用抽象工厂模式：
?一个系统不应当依赖于产品类实例怎么被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。
?这个系统有多于一个的产品族，而系统只消费其中某一产品族。
?同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。
?系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。
应用场景
?支持多种观感标准的用户界面工具箱（Kit）。
?游戏研发中的多风格系列场景，比如道路，房屋，管道等。
?……
总结
总之，抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，运用抽象工厂模式的关键点在于应对“多系列对象创建”的需求变化。一句话，学会了抽象工厂模式，你将理解OOP的精华：面向接口编程。
工厂方法模式： 一个抽象产品类，可以派生出多个具体产品类。 一个抽象工厂类，可以派生出多个具体工厂类。 每个具体工厂类只能创建一个具体产品类的实例。 抽象工厂模式： 多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。 一个抽象工厂类，可以派生出多个具体工厂类。 每个具体工厂类可以创建多个具体产品类的实例。 区别： 工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。 工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。 看了网络上很多关于设计模式的方法,有的模式看起来相似,但本质还是区别很大的.像简单工厂,工厂方法和抽象工厂就有很明显的区别. 有一个比较好理解的例子,在这跟大家介绍下: 1.如果一个后花园只种蔬菜类,那么就用简单工厂就可以了. 2.如果后花园蔬菜品种繁多.得用工厂方法才可以,把共有的东西抽象出来. 3.如果要扩大后花园的规模,比如一个在北方,一个在南方,这样工厂方法就无法实现了,就应当用抽象工厂,把各种各样的植物,又组成一个后花园. 所以我个人认为,简单工厂是一个工厂只生产一类的产品,面对的是具体的类,工厂方法是可以生产不同的产品,把公共的方法抽象出来,然后进行创建各种各样的产品.抽象工厂把几种产品划出共同的东西,把相互依赖的对象抽象出来,只要实现这些接口就可以得到不同的产品. 具体例子: 1.简单工厂: using System; public interface ICar { void run(); } public class BMWCar : ICar { public void run() { Console.WriteLine("BMWCar run"); } }
抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品族中的产品对象。根据LSP原则，任何接受父类型的地方，都应当能够接受子类型。因此，实际上系统所需要的，仅仅是类型与这些抽象产品角色相同的一些实例，而不是这些抽象产品的实例。换言之，也就是这些抽象产品的具体子类的实例。工厂类负责创建抽象产品的具体子类的实例。 当每个抽象产品都有多于一个的具体子类的时候，工厂角色怎么知道实例化哪一个子类呢？比如每个抽象产品角色都有两个具体产品。抽象工厂模式提供两个具体工厂角色，分别对应于这两个具体产品角色，每一个具体工厂角色只负责某一个产品角色的实例化。每一个具体工厂类只负责创建抽象产品的某一个具体子类的实例。 每一个模式都是针对一定问题的解决方案，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式针对的是多个产品等级结果。 下面是一个java抽象工厂的实现实例. 我们以交通工具(Vihicle),食品(Foot),武器(Weapon)为抽象产品类为例: 交通工具(Vihicle) public abstract class Vihicle { public abstract void run(); } 食品(Foot) public abstract class Foot { public abstract void printName(); } 武器(Weapon) public abstract class Weapon { public abstract void shoot(); } 这三种抽象产品类都有两种子类的实现: 交通工具(Vihicle)有实现类Car,Broom public class Car extends Vihicle{ public void run(){ System.out.println("冒着烟奔跑中的Car..."); } } public class Broom extends Vihicle{ public void run(){ System.out.println("一路沙尘暴飞奔而来.."); } } 食品(Foot)有实现类Mushroom,Apple
大连海事大学软件设计与体系结构 课程实验报告 （2016-2017学年第二学期） 实验四设计模式应用 班级：软件工程一班 学号：2220141524 姓名：孙正涛 指导教师：谢兄 成绩： 2016年1月2日
目录 1实验目的 (3) 2实验内容 (3) 3实验要求 (4) 4实验步骤 (4) 5总结与体会 (4) 5.1实验中出现的问题及其解决方案 (4) 5.2总结 (5) 5.3体会............................................................................................. 错误！未定义书签。
1实验目的 1.1利用Observer、单件等设计模式开发实现一个小的系统。 1.2通过常用的设计模式的实例实验，熟悉设计模式特点及应用条件，掌握基于设计模式的 软件系统的设计与开发应用。 2实验内容 2.1完成一个了一个可以绘图并进行移动的绘图程序 该程序分成分成8部分来写分别是：ShapeMgr.java MyCircle.java MyLine.java MyLocation.java MyRectangle.java MyShape.java IShape.java Painting.java 2.2ShapeMgr.java 这部分代码是负责几种管理图形的代码，将代码存在一个ArrayList 集合中，方便在移动的时候进行几种的管理 2.3MyCircle.java 这部分是关于绘制圆形的，里面有filloval()方法——这是用于绘图的方法，还有一个inside()方法，这是关于移动的函数，用于判断是否可以进行移动 2.4MyLine.java 与上一个类是一样的，用于绘制直线 2.5MyRectangle.java 与上一个类是一样的，用于绘制矩形 2.6MyLocation.java 这是一个负责进行初始地址管理的类，因为每次移动都需要变更地址，而图形的相对属性是不变的。就像是矩形开始点到终止点的距离，是不变的。确定了初始的地点，依据现有图形的一些属性，就可以重新绘制出移动后的另一个图形。每次只要是关于初始地点的X、Y都必须通过这个类来获取和改变，所以里面有get、set函数等。 这个类是图形移动的关键，所以设计的时候花费的时间比较多。 2.7MyShape.java 这个类继承了接口IShape接口，实现了它里面的方法，并且其他的类继承了这个类里面的方法，并进行一些改变。 这个类的作用主要是最坐标进行处理的，因为在移动的时候，只要是针对初始的X，Y 的值进行改变，然后在根据之前的一些属性进行重新绘制图形。 2.8IShape.java 这是一个父父接口，用于管理最常用的几个方法 MyLocation getMylocation(); void setMyLocation(MyLocation location); 这个方法是与MyShape类中的一个方法，用于获取之前的X，Y的地址，然后通过计算式进行改变地址的值，获取新的地址，然后在重新绘制出新的图形。 Int area();
抽象工厂模式可以向客户端提供一个接口，使得客户端在不必指定产品具体类型的情况下，创建多个产品族中的产品对象。这就是抽象工厂模式的用意。 每个模式都是针对一定问题的解决方案。抽象工厂模式面对的问题是多产品等级结构的系统设计。 在学习抽象工厂具体实例之前，应该明白两个重要的概念：产品族和产品等级。 产品族：是指位于不同产品等级结构中，功能相关联的产品组成的家族。比如AMD的CPU和ADM芯片的主板，组成一个家族。Intel的CPU和Intel芯片的主板，又组成一个家族。而这两个家族都来自于两个产品等级：CPU，主板。一个等级结构是由相同的结构的产品组成，示意图如下： 理解这个产品结构是理解抽象工厂模式的关键所在，所以我不惜花费时间来画此图。如果领悟不到此图的含义，就无法区分工厂方法模式和抽象工厂模式的区别。 从上图可以看出，抽象工厂模式的每个工厂创造出来的都是一族产品，而不是一个或者一组。组是可以随意组合的！其实两个就这点点差别，呵呵，估计现在你已经差不多明白了抽象工厂模式的含义。不废话了，看个例子，真相将大白于天下！ 1.3.1 抽象工厂模式在农场中的实现 1.3.1.1 背景 聪明的农场主总是让自己的庄园越来越有价值，“农场”在经历了简单工厂模式和工厂模式后，不断的扩大生产。如今，再次面临新的大发展，一项重要的工作就是引进塑料大棚技术，在大棚里种植热带（Trop ical）和亚热带（Northern）的水果和蔬菜，用以满足市场需求，获取更大的利益。 1.3.1.2 产品角色图 经过分析，对产品角色进行分析得出下图
1.3.1.3 系统设计 经过分析，所谓的各个园丁其实就是工厂角色，而蔬菜和水果则是产品角色。将抽象工厂模式用于农场中，系统设计图如下： 1.3.1.4 实现源码
实验一、教务系统 1. 实验目的： ①学习工厂模式； ②掌握简单工厂模式的用法，以及其优缺点； ③掌握抽象工厂模式的用法，以及其优缺点。 2. 实验内容： 1.假设我们开发一个教务管理系统，现在教务处已经购买了Oracle数据库的2年使用权，且数据库 中有大量数据，不能短时间内进行数据库迁移。教务处提出一个要求，希望我们的系统现在可以支持Oracle，但在他们需要的时候，增加支持MySql、SQLServer的功能，请用简单工厂模式实现这一需求。（提示：具体代码可以数据读取写入工作抽象为一行命令行输出，但是核心的类关系必须给出。） 2.请用抽象工厂模式实现出以上需求。 3. 简单工厂 优点： 1、工厂方法包含从一个类的结构中选择初始类的业务逻辑。 2、客户类不直接创建产品类的对象。客户类只作为对象的消费者。 3、简单工厂方法模式实现了责任分离。 4、客户类不负有创建类的对象的责任，因此如果有新产品子类加入，不必修改已有的客户类代码。 缺点： 1、简单工厂方法模式不符合开闭原则。 2、简单工厂类只能是一个单独的类，而不能成为一个层次的类 4. 抽象工厂 优点： 1、具体产品从客户代码中被分离出来 2、容易改变产品的系列 3、将一个系列的产品族统一到一起创建 缺点： 在产品族中扩展新的产品是很困难的，它需要修改抽象工厂的接口
5. 类图 6、实验总结 对于简单工厂和抽象工厂的学习有了初步的认识，在此学习中基本了解了什么情况下使用简单工厂和抽象工厂。 简单工厂： 1、工厂类负责创建的对象比较少； 2、客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心； 3、由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。 抽象工厂： 1、一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。 2、这个系统有多于一个的产品族，而系统只消费其中某一产品族。 3、同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。 4、系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。
工厂模式有以下几种形态: 简单工厂(Simple Factory)模式 工厂方法(Factory Method)模式,又称多形性工厂(Polymorphic Factory)模式 抽象工厂(Abstract Factory)模式,又称工具箱(Kit或Toolkit)模式 在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。 工厂方法模式是简单工厂模式的进一步抽象化和推广，工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给子类去作。
工厂方法模式和简单工厂模式在定义上的不同是很明显的。工厂方法模式的核心是一个抽象工厂类,而不像简单工厂模式, 把核心放在一个实类上。工厂方法模式可以允许很多实的工厂类从抽象工厂类继承下来, 从而可以在实际上成为多个简单工厂模式的综合,从而推广了简单工厂模式。 反过来讲,简单工厂模式是由工厂方法模式退化而来。设想如果我们非常确定一个系统只需要一个实的工厂类, 那么就不妨把抽象工厂类合并到实的工厂类中去。而这样一来,我们就退化到简单工厂模式了。 抽象工厂模式是所有形态的工厂模式中最为抽象和最具广泛性的一种形态，抽象工厂模式是工厂方法模式的进一步扩广化和抽象化。如下图：
在抽象工厂模式中，抽象产品(AbstractProduct) 可能是一个或多个，从而构成一个或多个产品族(Product Family)。在只有一个产品族的情况下，抽象工厂模式实际上退化到工厂方法模式。 总结：简单工厂模式是由一个具体的类去创建其他类的实例，父类是相同的，父类是具体的。 工厂方法模式是有一个抽象的父类定义公共接口，子类负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成。 抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类。它针对的是有多个产品的等级结构。而工厂方法模式针对的是一个产品的等级结构。
实验一单例模式的应用 1 实验目的 1) 掌握单例模式（Singleton）的特点 2) 分析具体问题，使用单例模式进行设计。 2 实验内容和要求 很多应用项目都有配置文件，这些配置文件里面定义一些应用需要的参数数据。 通常客户端使用这个类是通过new一个AppConfig的实例来得到一个操作配置文件内容的对象。如果在系统运行中，有很多地方都需要使用配置文件的内容，系统中会同时存在多份配置文件的内容，这会严重浪费内存资源。 事实上，对于AppConfig类，在运行期间，只需要一个对象实例就够了。那么应该怎么实现呢？用C#控制台应用程序实现该单例模式。绘制该模式的UML 图。 3 实验代码 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace AppConfig { publicclass Singleton { privatestatic Singleton instance; private Singleton() {
} publicstatic Singleton GetInstance() { if (instance == null) { instance = new Singleton(); } return instance; } } class Program { staticvoid Main(string[] args) { Singleton singletonOne = Singleton.GetInstance(); Singleton singletonTwo = Singleton.GetInstance(); if (singletonOne.Equals(singletonTwo)) { Console.WriteLine("singletonOne 和 singletonTwo 代表的是同一个实例"); } else { Console.WriteLine("singletonOne 和 singletonTwo 代表的是不同实例"); } Console.ReadKey(); } } } 4 实验结果
(4) 抽象工厂模式 电脑配件生产工厂生产内存、CPU等硬件设备，这些内存、CPU的品牌、型号并不一定相同，根据下面的“产品等级结构-产品族”示意图，使用抽象工厂模式实现电脑配件生产过程并绘制相应的类图，绘制类图并编程实现。 interface CPU {
void discribe(); } interface RAM { void discribe(); } class PcCPU implements CPU { public void discribe() { System.out.println("PcCPU"); } } class MacCPU implements CPU { public void discribe() { System.out.println("MacCPU"); } } class PcRAM implements RAM { public void discribe() { System.out.println("PcRAM"); } } class MacRAM implements RAM { public void discribe() { System.out.println("MacRAM"); } } interface ComputerPartsFactory { CPU produceCPU(); RAM produceRAM();
} class PcFactory implements ComputerPartsFactory { public PcCPU produceCPU() { System.out.println("PcCPU produced!"); return new PcCPU(); } public PcRAM produceRAM() { System.out.println("PcRAM produced!"); return new PcRAM(); } } class MacFactory implements ComputerPartsFactory { public MacCPU produceCPU() { System.out.println("MacCPU produced!"); return new MacCPU(); } public MacRAM produceRAM() { System.out.println("MacRAM produced!"); return new MacRAM(); } } class ComputerPartsClient { public static void main(String a[]) { ComputerPartsFactory factory; CPU cpu; RAM ram; factory=(ComputerPartsFactory)XMLUtil.getBean();//Pc OR Mac cpu=factory.produceCPU(); cpu.discribe(); ram=factory.produceRAM(); ram.discribe(); } }
?概述 在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。怎么应对这种变化？怎么绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程式和这种“多系列具体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。 意图 提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。 模型图 逻辑模型： 物理模型： 生活中的例子 抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不必指定他们具体的类。这种模式能汽车制造厂所
使用的金属冲压设备中找到。这种冲压设备能制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改动冲压盘，这个机械产生的具体类能在三分钟内改动。 抽象工厂之新解 虚拟案例 中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。 员工的工资= (基本工资+ 奖金- 个人所得税)。这是个放之四海皆准的运算法则。 为了简化系统，我们假设员工基本工资总是4000美金。 中国企业奖金和个人所得税的计算规则是: 奖金= 基本工资(4000) * 10% 个人所得税= (基本工资+ 奖金) * 40% 我们目前要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。 案例分析 奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)。 工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。 工资的计算作为业务规则的前端(或客户端Client)将提供给最终使用该系统的用户(财务人员)使用。
中南大学软件学院 软件体系结构 设计模式实验报告 学生姓名：宋昂 所在学院：软件学院 学生学号： 3901080115 学生班级：软件0801 指导老师：刘伟 完成日期： 2010-12-7
一、实验目的 熟练使用PowerDesigner和任意一种面向对象编程语言实现几种常见的设计模式，包括简单工厂模式、工厂方法模式、抽象工厂模式、单例模式和适配器模式，理解每一种设计模式的模式动机，掌握模式结构，学习如何使用代码实现这些模式，并学会分析这些模式的使用效果。 二、实验内容 使用PowerDesigner和任意一种面向对象编程语言实现简单工厂模式、工厂方法模式、抽象工厂模式、单例模式和适配器模式，包括根据实例绘制模式结构图、编写模式实例实现代码，运行并测试模式实例代码。 (1) 简单工厂模式 使用简单工厂模式设计一个可以创建不同几何形状(Shape)的绘图工具类，如可创建圆形(Circle)、方形(Rectangle)和三角形(Triangle) 对象，每个几何图形都要有绘制draw()和擦除erase()两个方法，要求在绘制不支持的几何图形时，提示一个UnsupportedShapeException，绘制类图并编程实现。 (2) 简单工厂模式 使用简单工厂模式模拟女娲(Nvwa)造人(Person)，如果传入参数“M”，则返回一个Man 对象，如果传入参数“W”，则返回一个Woman对象，使用任意一种面向对象编程语言实现该场景。现需要增加一个新的Robot类，如果传入参数“R”，则返回一个Robot对象，对代码进行修改并注意女娲的变化。 (3) 工厂方法模式 某系统日志记录器要求支持多种日志记录方式，如文件记录、数据库记录等，且用户可以根据要求动态选择日志记录方式，现使用工厂方法模式设计该系统。用代码实现日志记录器实例，如果在系统中增加一个中的日志记录方式——控制台日志记录(ConsoleLog)，绘制类图并修改代码，注意增加新日志记录方式过程中原有代码的变化。
下面就来看一个Demo ，从这个Demo 中看出抽象工厂的优点 先来展现一下具体的类图 上面的类图呢，说明的是有两个具体工厂，一个是Linux 控件的制造，还有一个是Windows 控件的制造， 然后，有两个产品族，一个是WindowsTextBox 和LinuxTextBox 组成的TextBox 产品族，还有一个就是WindowsButton 和LinuxButton 组成的Button 产品族。 下面就来写类了 先来看工厂类吧 namespace AbstractFactory { public abstract class AbstractFactory { //在抽象工厂中，应该包含所有产品创建的抽象方法
public abstract Button CreateButton(); public abstract TextBox CreateTextBox(); } } namespace AbstractFactory { public class WindowsFactory:AbstractFactory { public override Button CreateButton() { return new WindowsButton(); } public override TextBox CreateTextBox() { return new WindowsTextBox(); } } } namespace AbstractFactory { public class LinuxFactory:AbstractFactory { public override Button CreateButton() { return new LinuxButton(); } public override TextBox CreateTextBox() { return new LinuxTextBox(); }
工厂模式的三种类型： 1抽象工厂模式是所有形态的工厂模式中最为抽 象和最其一般性的。抽象工厂模式可以向客户端 提供一个接口，使得客户端在不必指定产品的具 体类型的情况下，能够创建多个产品族的产品对 象。 1.抽象工厂（Creator）角色 抽象工厂模式的核心，包含对多个产品结构的声明，任何工厂类都必须实现这个接口。 2.具体工厂（Concrete Creator）角色 具体工厂类是抽象工厂的一个实现，负责实例化某个产品族中的产品对象。 3.抽象（Product）角色 抽象模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 4.具体产品（Concrete Product）角色 抽象模式所创建的具体实例对象 总结：抽象工厂中方法对应产品结构，具体工厂对应产品族。 2工厂方法模式同样属于类的创建型模式又被称 为多态工厂模式。工厂方法模式的意义是定义一个创建 产品对象的工厂接口，将实际创建工作推迟到子类当中。 核心工厂类不再负责产品的创建，这样核心类成为一个 抽象工厂角色，仅负责具体工厂子类必须实现的接口， 这样进一步抽象化的好处是使得工厂方法模式可以使系 统在不修改具体工厂角色的情况下引进新的产品。
1.抽象工厂（Creator）角色 工厂方法模式的核心，任何工厂类都必须实现这个接口。 2.具体工厂（Concrete Creator）角色 具体工厂类是抽象工厂的一个实现，负责实例化产品对象。 3.抽象（Product）角色 工厂方法模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 4.具体产品（Concrete Product）角色 工厂方法模式所创建的具体实例对象 工厂方法模式与简单工厂模式在结构上的不同不是很明显。工厂方 法类的核心是一个抽象工厂类，而简单工厂模式把核心放在一个具 体类上。 工厂方法模式之所以有一个别名叫多态性工厂模式是因为具体工 厂类都有共同的接口，或者有共同的抽象父类。 当系统扩展需要添加新的产品对象时，仅仅需要添加一个具体对 象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也 不需要修改客户端，很好的符合了“开放－封闭”原则。而简单工厂 模式在添加新产品对象后不得不修改工厂方法，扩展性不好。 工厂方法模式退化后可以演变成简单工厂模式。 3简单工厂模式属于类的创建型模式,又叫做静态 工厂方法模式。通过专门定义一个类来负责创建 其他类的实例，被创建的实例通常都具有共同的 父类。 1.工厂（Creator）角色 简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。 2.抽象（Product）角色 简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 3.具体产品（Concrete Product）角色
《软件体系结构》大作业（1） 学院：软件学院 课程名称：软件体系结构 专业班级： 学生姓名：学号： 学生姓名：学号： 指导教师： 完成时间：年月日 评分表 1、叙述各小组成员完成本题目的分工协作情况。 小组中的每个成员都先理解题目要求及涉及的设计模式，并一起完成代码编写。另外，组长负责文档制作。 2、评分表 序号姓名评分是否组长 1 2 作业正文需要包括以下内容： 1、作业题目内容的详细描述。 2、完成本题目所采用的软件设计模式名称及画出相应的类图，或者是所采用的 软件体系结构名称及画出相应的体系结构图。
3、画出完成本题目所设计程序的设计类图；如还有其他图，也一并画出。 4、完成本题目所设计的程序代码。 5、程序运行的典型界面截图
1、作业题目内容的详细描述。 【作业2.1-1】例2.3为使用工厂方法模式设计的汽车保险管理应用程序实例。现在需要 扩展例2.3的设计图，添加一个名为LuxuryCarInsurance的类，并且需要编写此类和其他需要添加的类的代码，详细要求参见光盘的相应作业部分。 【作业2.1-1】在例2.4中，设计并且实现了豪华（Super）和中等（Medium）别墅（House）与公寓（Condo）的查询。要求在该设计的基础上，增加一个新的类SemiDetacher（半独立式楼宇），并且编写代码，实现相应的查询功能，详细要求参见光盘的相应作业部分。 2、完成本题目所采用的软件设计模式名称及画出相应的类图，或者是所采用的软件体系结构名称及画出相应的体系结构图。 【作业2.1-1】采用的是工厂方法模式 【作业2.1-2】采用的是抽象方法模式
抽象工厂模式 概述 在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具·体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。 意图 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类 模型图 逻辑模型： 物理模型： 生活中的例子 抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。这种模式可以汽车制造厂所使用的金属冲压设备中找到。这种冲压设备可以制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改变冲压盘，这个机械产生的具体类可以在三分钟内改变。 抽象工厂之新解 虚拟案例 中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。 员工的工资 = (基本工资 + 奖金 - 个人所得税)。这是一个放之四海皆准的运算法则。
为了简化系统，我们假设员工基本工资总是4000美金。 中国企业奖金和个人所得税的计算规则是: 奖金 = 基本工资(4000) * 10% 个人所得税 = (基本工资 + 奖金) * 40% 我们现在要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。 案例分析 奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)。 工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。 工资的计算作为业务规则的前端(或者客户端Client)将提供给最终使用该系统的用户(财务人员)使用。 针对中国企业为系统建模 根据上面的分析，为Softo系统建模如下： 代码： 针对美国企业为系统建模 为了拓展国际市场，我们要把该系统移植给美国公司使用。 美国企业的工资计算同样是: 员工的工资 = 基本工资 + 奖金 - 个人所得税。 但是他们的奖金和个人所得税的计算规则不同于中国企业: 美国企业奖金和个人所得税的计算规则是:
题目：抽象工厂模式 学生姓名张婧 学号20XX21077 院系信息科学与技术学院专业计算机应用技术 年级20XX 级
抽象工厂模式 在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？这就要用到抽象工厂模式。抽象工厂模式是简单工厂模式和工厂方法模式的升级版，它有更大的灵活性,同时也更加复杂一些。 为了理解抽象工厂,我们考虑这样一个实际例子:如果你想吃饭了，怎么办自己做吗？自己做就相当于程序中直接使用new。当然是自己下个指令，别人来做更爽。那就把做饭的任务交给厨师吧，那么他就是一个做饭的工厂了，你告诉他要吃红烧肉，等会他就从厨房给你端出来一盘香喷喷的红烧肉了，再来个清蒸鱼吧。下图 1 就是这个问题的模型。 图1 显然到了这里，你是Client，厨师就是工厂，他拥有做红烧肉的方法，做清蒸鱼的方法，这些方法返回值就是食物抽象。红烧肉、清蒸鱼就是食物的继承类，简单工厂模式也成型了。
简单工厂模式结构 图2 优点：允许客户端相对独立的创建产品的过程，并且在系统引入新产品的时候无需修改客户端。 缺点：对修改不封闭，新增加产品您要修改工厂。违法了开闭法则（OCP）。 工厂方法模式生活例子: 厨师手艺再好，总有不会做的菜，你想吃回锅肉，怎么办，让厨师学呗，于是就给他新增了做回锅肉的方法，以后你再想吃一个新菜，就要给厨师新加一个方法，显然此做法的缺点也就暴露出来了，用程序设计的描述就是对修改永远不能封闭。 面对上面对修改不能封闭的问题，有没有好的解决方案吗？把厨师抽象变成一个基类，你请几个具体的厨师，分别有做清蒸鱼的，做红烧肉的厨师，如果你想吃一个新菜，就再新找个厨师，从你的厨师基类继承一下，让他来做这个新菜。现在来看这个模式发生了变化，结构中多了一个厨师的抽象，抽象并不具体的加工产品了，至于做什么，是由这个抽象工厂的继承子类来实现，现在的模式也就变成工厂方法模式了，这个上面的结构图1就变成了下面的图3的结构了。
实验8 抽象工厂和建造者模式 一、实验目的 1、掌握抽象工厂模式的概念、模式结构、适用场景、优点和缺点。 3、掌握建造者模式的概念、模式结构、适用场景、优点和缺点。 二、实验环境 Windows操作系统，Rational Rose，eclipse、Myeclipse ，VS Studio，记事本等等。 三、实验内容 1、抽象工厂模式：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。 抽象工厂的模式图如下所示。模式中包含4个角色，抽象工厂、具体工厂、抽象产品和具体产品。
题目描述：我们在上一节讲了女娲造人的故事。人是造出来了，世界也热闹了，可是低头一看，都是清一色的类型，缺少关爱、仇恨、喜怒哀乐等情绪，人类的生命太平淡了，女娲一想，猛然一拍脑袋，记给人类定义性别了，那怎么办？ 由于女娲之前的准备工作花费了非常大的精力，比如准备黄土，准备八卦炉等，从头开始建立所有的事物也是不可能的，那就想在现有的条件下重新造人，尽可能旧物利用嘛。怎么才能让人类有爱有恨呢？是神仙当然办法的了，定义互斥的性别，然后在每个个体中埋下一颗种子：异性相吸，成熟后就一定会去找个异性（这就是我们说的爱情原动力）。从设计角度来看，一个具体的对象通过两个坐标就可以确定：肤色和性别。 产品类分析完毕了，生产的工厂类该（八卦炉）怎么改造呢？只有一个生产设备，要么生产出全都是男性，要么都是女性，那不行呀，这么大的翻天覆地的改造就是为了产生不同性别的人类。有办法了！把目前已经有的生产设备——八卦炉拆开，于是女娲就使用了“八卦拷贝术”，把原先的八卦炉一个变两个，并且略加修改，就成了女性八卦炉（只生产女性人种）和男性八卦炉（只生产男性人种），于是乎女娲就开始准备生产了。根据描述，请使用抽象工厂模式，画出UML类图，实现题目描述的功能。 UML类图:
简单工厂模式，工厂方法模式和抽象工厂模式的异同 简单工厂模式，工厂方法模式和抽象工厂模式都是属于创建型设计模式，这三种创建型模式都不需要知道具体类。我们掌握一种思想，就是在创建一个对象时，需要把容易发生变化的地方给封装起来，来控制变化（哪里变化，封装哪里），以适应客户的变动，项目的扩展。用这三种设计模式都可以实现，那究竟这三种设计模式有什么异同呢？下面根据这三者之间的特点，优点，缺点，适用范围进行比较。 一．特点 简单工厂模式：专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有 共同的父类。它又称为静态工厂方法模式。它的实质是由一个工厂 类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类 继承自一个父类或接口）的实例。简单工厂模式的创建目标，所有 创建的对象都是充当这个角色的某个具体类的实例。在这个模式中， 工厂类是整个模式的关键所在。它包含必要的判断逻辑，能够根据 外界给定的信息，决定究竟应该创建哪个具体类的对象。用户在使 用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象 是如何创建以及如何组织的。有利于整个软件体系结构的优化。 工厂方法模式：工厂方法是粒度很小的设计模式，因为模式的表现只是一个抽象的方法。 提前定义用于创建对象的接口，让子类决定实例化具体的某一个类，即 在工厂和产品中间增加接口，工厂不再负责产品的创建，由接口针对不 同条件返回具体的类实例，由具体类实例去实现。工厂方法模式是简单 工厂模式的衍生，解决了许多简单工厂模式的问题。首先完全实现‘开 －闭原则’，实现了可扩展。其次实现更复杂的层次结构，可以应用于 产品结果复杂的场合。工厂方法模式是对简单工厂模式进行了抽象。有 一个抽象的Factory类（可以是抽象类和接口），这个类将不在负责具 体的产品生产，而是只制定一些规范，具体的生产工作由其子类去完成。 在这个模式中，工厂类和产品类往往可以依次对应。即一个抽象工厂对 应一个抽象产品，一个具体工厂对应一个具体产品，这个具体的工厂就 负责生产对应的产品。
我的空间主页|空间装扮博客|写新文章相册|上传照片好友|找新朋友档案|留言板我的应用loading.. 我的i贴吧i动态传送门我的动态jljHappyDay 1 | 我的消息(0/0) | 我的空间| 我的应用| 我的i贴吧| 百度空间| 百度首页| 退出踏浪帅的空间https://www.doczj.com/doc/2016245172.html, C# 资料收藏主页博客相册|个人档案|好友查看文章 NET设计模式(4): 抽象工厂模式（实例代码）2009-11-29 00:18实例： 大家知道，动物世界中各大陆的动物是不一样的，各种动物可以分成两样，一种食草，一种食肉。食肉的动物吃食草动物。美洲狼属于食肉动物，野牛属于食草动物，美洲狼吃野牛。非洲的狮子属于食肉动物，角马属于食草动物，狮子吃角马。类图如下： 代码： using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace AnimalWorld { // 抽象大陆工厂 abstract class ContinentFactory { abstract public Herbivore CreateHerbivore(); //抽象创建食草动物的类，返回食草类动物 abstract public Carnivore CreateCarnivore(); //抽象创建食肉动物的类，返回食肉类动物 } //非洲大陆,有角马，狮子 class AfricaFactory : ContinentFactory //非洲动物工厂类 { override public Herbivore CreateHerbivore() //实现上面的抽象方法，注意返回类型 { return new Wildebeest(); //实例化一个角马，角马是食草动物 } override public Carnivore CreateCarnivore() //实现上面的抽象方法，注意返回类型 { return new Lion(); //实例化一个狮子，狮子是食肉动物 }
太原师范学院 实验报告 Experimentation Report of Taiyuan teachers College 系部计算机系年级课程设计模式实训教程 姓名学号日期2018.03.03 项目 Factory Method设计模式 一、实验目的 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。 框架使用抽象类定义和维护对象之间的关系。这些对象的创建通常也由框架负责。考虑这样一个应用框架，它可以向用户显示多个文档。在这个框架中，两个主要的抽象是类Application和Document。这两个类都是抽象的，客户必须通过它们的子类来做与具体应用相关的实现。 二、实验原理 试验要求包含典型的 Factory Method结构。 程序能够明确表达设计思想。 三、实验仪器及材料 操作系统： Windows，linux； 开发工具： VC； Java，C# 四、实验方法 设计一个Factory Method案例并实现，并撰写设计报告。
五、实验记录及数据处理 interface Log{ public void writeLog(); } //文件日志记录器：具体产品 class FileLog implements Log{ @Override public void writeLog() { System.out.println("文件日志记录。"); } } //数据库日志记录器：具体产品 class DatebaseLog implements Log{ @Override public void writeLog() { System.out.println("数据库日志记录。"); } } //日志记录器工厂接口：抽象工厂 interface LogFactory{ public Log createLog(); } //文件日志记录器工厂类：具体工厂 class FileLogFactory implements LogFactory{ @Override public Log createLog() { return new FileLog(); } } //数据库日志记录器工厂类：具体工厂 class DatabaseLogFactory implements LogFactory{ @Override public Log createLog() {
软件设计模式实验报告 篇一：软件设计模式实验报告 计算机科学与技术学院实验报告 课程名称：专业：班级：学号：姓名： 实验一单例模式的应用 1 实验目的 1) 掌握单例模式（Singleton）的特点 2) 分析具体问题，使用单例模式进行设计。 2 实验内容和要求 很多应用项目都有配置文件，这些配置文件里面定义一些应用需要的参数数据。 通常客户端使用这个类是通过new 一个AppConfig的实例来得到一个操作配置文件内容的对象。如果在系统运行
中，有很多地方都需要使用配置文件的内容，系统中会同时存在多份配置文件的内容，这会严重浪费内存资源。 事实上，对于AppConfig类，在运行期间，只需要一个对象实例就够了。那么应该怎么实现呢？用C#控制台应用程序实现该单例模式。绘制该模式的UML图。 UML图： 源代码： class Program { static void Main { AppConfig appConfigOne = ; AppConfig appConfigTwo = ; if ) { ; } else {
; } ; } } } 运行结果： 实验小结： 通过这次实验，我了解了单例模式的具体概念和使用方法，并且感受到了他的优点带来的方便，但是同时也知道了该设计模式的缺点：由于单例模式中没有抽象层，因此单例类的扩展有很大困难。 实验二工厂模式的应用 1 实验目的 1) 掌握工厂模式（ Factory ）的特点 2) 分析具体问题，使用工厂模式进行设计。 2 实验内容和要求 有一个OEM制造商代理做HP笔记
本电脑，后来该制造商得到了更多的品牌笔记本电脑的订单Acer，Lenovo，Dell，该OEM商发现，如果一次同时做很多个牌子的本本，有些不利于管理。利用工厂模式改善设计，用C#控制台应用程序实现该OEM制造商的工厂模式。绘制该模式的UML图。UML 图： 源代码：class Laptop { public virtual void GetLaptop { } } class HpLaptop:Laptop { public override void GetLaptop { ; } } class AcerLaptop : Laptop {