.NET设计模式（3）：抽象工厂模式（Abstract Factory）
抽象工厂模式（Abstract Factory）
——探索设计模式系列之三
Terrylee，2005年12月12日概述
在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。
意图
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
模型图
逻辑模型：
物理模型：
生活中的例子
抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。这种模式可以汽车制造厂所使用的金属冲压设备中找到。这种冲压设备可以制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改变冲压盘，这个机械产生的具体类可以在三分钟内改变。
抽象工厂之新解
虚拟案例
中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。
员工的工资 = (基本工资 + 奖金 - 个人所得税)。这是一个放之四海皆准的运算法则。
为了简化系统，我们假设员工基本工资总是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、A mericanBonus。修改后的模型如下：
则业务规则Service类的代码如下：
1using System;
2
3namespace AmericanSalary
4{
5///
6///公用的常量
7///
8public class Constant
9 {
10public static double BASE_SALARY = 4000;
11 }
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
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 {
13 AmericanBonus bonus = new AmericanBonus();
14double bonusValue = bonus.Calculate();
15
16 AmericanTax tax = new AmericanTax();
17double taxValue = tax.Calculate();
18
19double 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和ChineseTa x、ChineseBonus分别实现这两个接口，据此修正后的模型如下：
此时客户端代码如下：
1
2using System;
4namespace InterfaceSalary
5{
6///
7///客户端程序调用
8///
9public class Calculator
10 {
11public static void Main(string[] args)
12 {
13 Bonus bonus = new ChineseBonus();
14double bonusValue = bonus.Calculate();
15
16 Tax tax = new ChineseTax();
17double taxValue = tax.Calculate();
18
19double salary = 4000 + bonusValue - taxValue;
20
21 Console.WriteLine("Chinaese Salary is：" + salary);
22 Console.ReadLine();
23 }
24 }
26
为业务规则增加工厂方法
然而，上面增加的接口几乎没有解决任何问题，因为当系统的客户在美国和中国企业间切换时C aculator代码仍然需要修改。
只不过修改少了两处，但是仍然需要修改ChineseBonus,ChineseTax部分。致命的问题是：我们需要将这个移植工作转包给一个叫Hippo的软件公司。由于版权问题，我们并未提供Softo系统的源码给Hippo公司，因此Hippo公司根本无法修改Calculator，导致实际上移植工作无法进行。
为此，我们考虑增加一个工具类(命名为Factory)，代码如下：
1using System;
2
3namespace FactorySalary
4{
5///
6/// Factory类
7///
8public class Factory
9 {
10public Tax CreateTax()
11 {
12return new ChineseTax();
13 }
14
15public Bonus CreateBonus()
16 {
17return new ChineseBonus();
18 }
19 }
20}
21
修改后的客户端代码：
1
2using System;
3
4namespace FactorySalary
5{
6///
7///客户端程序调用
8///
9public class Calculator
10 {
11public static void Main(string[] args) 12 {
13 Bonus bonus = new Factory().CreateBonus();
14double bonusValue = bonus.Calculate();
15
16 Tax tax = new Factory().CreateTax();
17double taxValue = tax.Calculate();
18
19double 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///
6/// Factory类
7///
8public class Factory
9 {
10public Tax CreateTax()
11 {
12return new AmericanTax();
13 }
14
15public Bonus CreateBonus()
16 {
17return 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///
7/// AbstractFactory类
8///
9public abstract class AbstractFactory
10 {
11public static AbstractFactory GetInstance()
12 {
13string factoryName = Constant.STR_FACTORYNAME.ToString(); 14
15 AbstractFactory instance;
16
17if(factoryName == "ChineseFactory")
18 instance = new ChineseFactory();
19else if(factoryName == "AmericanFactory")
20 instance = new AmericanFactory();
21else
22 instance = null;
23
24return instance;
25 }
26
27public abstract Tax CreateTax();
28
29public abstract Bonus CreateBonus();
30 }
31}
配置文件：
1
2
3
4
5
6
7
采用上面的解决方案，当系统在美国企业和中国企业之间切换时，我们需要做什么移植工作？答案是: 我们仅仅需要修改配置文件，将factoryName的值改为American。
修改配置文件的工作很简单，只要写一篇幅配置文档说明书提供给移植该系统的团队(比如Hipp o公司) 就可以方便地切换使该系统运行在美国或中国企业。
最后的修正（不是最终方案）
前面的解决方案几乎很完美，但是还有一点瑕疵，瑕疵虽小，但可能是致命的。
考虑一下，现在日本NEC公司决定购买该系统，NEC公司的工资的运算规则遵守的是日本的法律。如果采用上面的系统构架，这个移植我们要做哪些工作呢?
1. 增加新的业务规则类JapaneseTax,JapaneseBonus分别实现Tax和Bonus接口。
工厂方法模式： 一个抽象产品类，可以派生出多个具体产品类。 一个抽象工厂类，可以派生出多个具体工厂类。 每个具体工厂类只能创建一个具体产品类的实例。 抽象工厂模式： 多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。 一个抽象工厂类，可以派生出多个具体工厂类。 每个具体工厂类可以创建多个具体产品类的实例。 区别： 工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。 工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。 看了网络上很多关于设计模式的方法,有的模式看起来相似,但本质还是区别很大的.像简单工厂,工厂方法和抽象工厂就有很明显的区别. 有一个比较好理解的例子,在这跟大家介绍下: 1.如果一个后花园只种蔬菜类,那么就用简单工厂就可以了. 2.如果后花园蔬菜品种繁多.得用工厂方法才可以,把共有的东西抽象出来. 3.如果要扩大后花园的规模,比如一个在北方,一个在南方,这样工厂方法就无法实现了,就应当用抽象工厂,把各种各样的植物,又组成一个后花园. 所以我个人认为,简单工厂是一个工厂只生产一类的产品,面对的是具体的类,工厂方法是可以生产不同的产品,把公共的方法抽象出来,然后进行创建各种各样的产品.抽象工厂把几种产品划出共同的东西,把相互依赖的对象抽象出来,只要实现这些接口就可以得到不同的产品. 具体例子: 1.简单工厂: using System; public interface ICar { void run(); } public class BMWCar : ICar { public void run() { Console.WriteLine("BMWCar run"); } }
创建型模式概述 创建型模式(Creational Pattern)对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰，外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。 模式动机 考虑一个简单的软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等），这些按钮都源自同一个基类，不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观，如果我们希望在使用这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象，此时，就可以使用简单工厂模式。模式定义 简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。 模式分析 将对象的创建和对象本身业务处理分离可以降低系统的耦合度，使得两者修改起来都相对容易。 在调用工厂类的工厂方法时，由于工厂方法是静态方法，使用起来很方便，可通过类名直接调用，而且只需要传入一个简单的参数即可，在实际开发中，还可以在调用时将所传入的参数保存在XML等格式的配置文件中，修改参数时无须修改任何Java源代码。 简单工厂模式最大的问题在于工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，这一点与开闭原则是相违背的。 简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。 简单工厂模式的不足 在简单工厂模式中，只提供了一个工厂类，该工厂类处于对产品类进行实例化的中心位置，它知道每一个产品对象的创建细节，并决定何时实例化哪一个产品类。简单工厂模式最大的缺点是当有新产品要加入到系统中时，必须修改工厂类，加入必要的处理逻辑，这违背了“开闭原则”。在简单工厂模式中，所有的产品都是由同一个工厂创建，工厂类职责较重，业务逻辑较为复杂，具体产品与工厂类之间的耦合度高，严重影响了系统的灵活性和扩展性，而工厂方法模式则可以很好地解决这一问题。 模式动机 考虑这样一个系统，按钮工厂类可以返回一个具体的按钮实例，如圆形按钮、矩形按钮、菱形按钮等。在这个系统中，如果需要增加一种新类型的按钮，如椭圆形按钮，那么除了增加一个新的具体产品类之外，还需要修改工厂类的代码，这就使得整个设计在一定程度上违反了“开闭原则”。 模式定义 工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。 模式分析 工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了面向对象的多态性，工厂方
抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品族中的产品对象。根据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();
Java设计模式之工厂模式(Factory) 时间：2009-08-04 17:23 来源：未知作者：和水柔石 CSDN IE QQ百度我挖Google POCO Yahoo新浪365Key天极和讯博拉Live奇客鲜果收客饭否叽歪挖客 核心提示：作者：和水柔石一、引子话说十年前，有一个爆发户，他家有三辆汽车（Benz （奔驰）、Bmw （宝马）、Audi （奥迪）看来这人比较爱国，没有日本车），还雇了司机为他开车。不过，爆发户坐车时总是这样：上Benz 车后跟司机说开奔驰车！，坐上Bmw 后他说开 作者：和水柔石 一、引子 话说十年前，有一个爆发户，他家有三辆汽车（Benz （奔驰）、Bmw （宝马）、Audi （奥迪）看来这人比较爱国，没有日本车），还雇了司机为他开车。不过，爆发户坐车时总是这样：上Benz 车后跟司机说" 开奔驰车！" ，坐上Bmw 后他说" 开宝马车！" ，坐上Audi 后他说" 开奥迪车！" 。你一定说：这人有病！直接说开车不就行了？！而当把这个爆发户的行为放到我们程序语言中来，我们发现C 语言一直是通过这种方式来坐车的！幸运的是，这种有病的现象在OO 语言中可以避免了。下面以Java 语言为基础来引入我们本文的主题：工厂模式！！ 二、简介 工厂模式主要是为创建对象提供了接口。工厂模式按照《Java 与模式》中的提法分为三类： 1. 简单工厂模式(Simple Factory) 2. 工厂方法模式(Factory Method) 3. 抽象工厂模式(Abstract Factory) 这三种模式从上到下逐步抽象，并且更具一般性。还有一种分类法，就是将简单工厂模式看为工厂方法模式的一种特例，两个归为一类。下面是使用工厂模式的两种情况： 1. 在编码时不能预见需要创建哪种类的实例。 2. 系统不应依赖于产品类实例如何被创建、组合和表达的细节 三、简单工厂模式 顾名思义，这个模式本身很简单，而且使用在业务较简单的情况下。 它由三种角色组成（关系见下面的类图）： 1、工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java 中它往往由一个具体类实现。 2、抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java 中由接口或者抽象类来实现。 3、具体产品角色：工厂类所创建的对象就是此角色的实例。在java 中由一个具体类实现。
抽象工厂模式可以向客户端提供一个接口，使得客户端在不必指定产品具体类型的情况下，创建多个产品族中的产品对象。这就是抽象工厂模式的用意。 每个模式都是针对一定问题的解决方案。抽象工厂模式面对的问题是多产品等级结构的系统设计。 在学习抽象工厂具体实例之前，应该明白两个重要的概念：产品族和产品等级。 产品族：是指位于不同产品等级结构中，功能相关联的产品组成的家族。比如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)将提供给最终使用该系统的用户(财务人员)使用。
简单工厂设计模式 目录 1.1摘要 (2) 2.1关键字 (2) 3.1开发工具 (2) 4.1简单工厂模式动机与定义： (2) 4.1.1模式动机 (2) 4.1.2模式定义 (2) 5.1简单工厂模式结构 (3) 6.1简单工厂模式实例： (4) 6.1.1代码分析 (4) 6.1.1.1Product（Shape抽象类）代码： (4) 6.1.1.2ConcreteProduct（Juxing,YuanXing,SanJiao具体产品类）代码：5 JuXing类： (5) YuanXing类： (6) SanJiao类： (6) 6.1.1.3Factory(Factory类)代码： (7) 6.1.1.4 (main类)： (7) 6.1.1.5运行结果： (10) 7.1结论 (10) 8.1参考文献： (10)
1.1摘要 本文从面向对象的角度对java接口的概念、作用以及使用它的好处做分析，讲解面向接口编程的方法，结合初步接触软件开发的人员习惯，从简单工厂设计模式的概念和其结构以及用途进行解析，重点讲解简单工厂设计模式在软件开发过程中的作用和好处，通过一些实例来说明简单工厂设计模式的特点。 2.1关键字 面向对象；java接口；接口编程；简单工厂设计模式。 3.1开发工具 Eclipse java语言开发 4.1简单工厂模式动机与定义： 在实际的软件开发过程中有时需要创建一些来自于相同父类的类的实例，为此可以专门定义一个类来负责创建这些类的实例，这些被创建的实例具有共同的父类。在这种情况下，可以通过传入不同的参数从而获取不同的对象，理由Java语言的特征，习惯上将创建其他类实例的方法定义为static方法，外部不需要实例化这个类就可以直接调用该方法来获得需要的对象，该方法也成为静态工厂方法。 4.1.1模式动机 考虑一个简单的软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮，矩形按钮等），这些按钮都源自同一个基类，不过在继承基类之后不同的子类修改了部分属性从而使得它们可以呈现不同的外观，如果我们希望在使用这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮的一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象，此时，就可以使用简单工厂模式。 4.1.2模式定义 简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常具有共同的父类。
中南大学软件学院 软件体系结构 设计模式实验报告 学生姓名：宋昂 所在学院：软件学院 学生学号： 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)，绘制类图并修改代码，注意增加新日志记录方式过程中原有代码的变化。
实验三工厂方法设计模式 实验目的：加深对工厂方法设计模式及创建型设计模式原理的理解 实验环境：C#.Net 实验内容： 某系统日志记录器要求支持多种日志记录方式，如文件日志记录和到数据库日志记录等，且用户在应用场景下可以根据要求动态选择日志记录方式，现使用工厂方法设计模式设计该系统。 实验过程： 1、构建实现场景，画出UML类图 2、实现代码(C#) static void Main(string [] args) { Console .WriteLine("采用文件日志记录方式"); ILogFactory fileLogFactory = new FileLogFactory(); Log filelog = fileLogFactory .CreateLog();
filelog .write(); Console .WriteLine("=============================="); Console .WriteLine("采用数据库日志记录方式"); ILogFactory databaseLogFactory = new DatabaseLogFactory(); Log databaseLog = databaseLogFactory .CreateLog(); databaseLog .write(); } ///
工厂模式的三种类型： 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】采用的是抽象方法模式
下面就来看一个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(); }
工厂方法模式（Factory Method) 耦合关系： 动机(Motivation): 在软件系统中，由于需求的变化，"这个对象的具体实现"经常面临着剧烈的变化，但它却有比较稳定的接口。 如何应对这种变化呢？提供一种封装机制来隔离出"这个易变对象"的变化，从而保持系统中"其它依赖的对象"不随需求的变化而变化。 意图(Intent): 定义一个用户创建对象的接口，让子类决定实例哪一个类。Factory Method使一个类的实例化延迟到子类。 ----------《设计模式》GOF 结构图(Struct):
生活实例： 适用性： 1.当一个类不知道它所必须创建的对象类的时候。 2.当一个类希望由它子类来指定它所创建对象的时候。 3.当类将创建对象的职责委托给多个帮助子类中的某个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。 实例代码： CarFactory类： 1public abstract class CarFactory 2{ 3public abstract Car CarCreate(); 4} Car类： 1public abstract class Car 2{ 3public abstract void StartUp(); 4public abstract void Run(); 5public abstract void Stop(); 6 7} HongQiCarFactory类：
1public class HongQiCarFactory:CarFactory 2{ 3public override Car CarCreate() 4{ 5return new HongQiCar(); 6} 7} BMWCarFactory类： 1public class BMWCarFactory:CarFactory 2{ 3public override Car CarCreate() 4{ 5return new BMWCar(); 6} 7} HongQiCar类： 1public class HongQiCar:Car 2{ 3public override void StartUp() 4{ 5Console.WriteLine("Test HongQiCar start-up speed!"); 6} 7public override void Run() 8{ 9Console.WriteLine("The HongQiCar run is very quickly!"); 10} 11public override void Stop() 12{ 13Console.WriteLine("The slow stop time is3second"); 14} 15} BMWCar类： 1public class BMWCar:Car 2{
抽象工厂模式 概述 在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具·体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。 意图 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类 模型图 逻辑模型： 物理模型： 生活中的例子 抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。这种模式可以汽车制造厂所使用的金属冲压设备中找到。这种冲压设备可以制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改变冲压盘，这个机械产生的具体类可以在三分钟内改变。 抽象工厂之新解 虚拟案例 中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。 员工的工资 = (基本工资 + 奖金 - 个人所得税)。这是一个放之四海皆准的运算法则。
为了简化系统，我们假设员工基本工资总是4000美金。 中国企业奖金和个人所得税的计算规则是: 奖金 = 基本工资(4000) * 10% 个人所得税 = (基本工资 + 奖金) * 40% 我们现在要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。 案例分析 奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)。 工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。 工资的计算作为业务规则的前端(或者客户端Client)将提供给最终使用该系统的用户(财务人员)使用。 针对中国企业为系统建模 根据上面的分析，为Softo系统建模如下： 代码： 针对美国企业为系统建模 为了拓展国际市场，我们要把该系统移植给美国公司使用。 美国企业的工资计算同样是: 员工的工资 = 基本工资 + 奖金 - 个人所得税。 但是他们的奖金和个人所得税的计算规则不同于中国企业: 美国企业奖金和个人所得税的计算规则是: