抽象工厂模式(Abstract Factory Pattern)

http://www.cnblogs.com/zhenyulu/category/6930.html  (设计模式 - 吕震宇)

http://www.cnblogs.com/Terrylee/archive/2006/07/17/334911.html  (.NET设计模式系列文章)

C#设计模式（6）－Abstract Factory Pattern

http://www.cnblogs.com/zhenyulu/articles/36885.html

一、 抽象工厂（Abstract Factory）模式

抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。

为了方便引进抽象工厂模式，引进一个新概念：产品族（Product Family）。所谓产品族，是指位于不同产品等级结构，功能相关联的产品组成的家族。如图：

 

图中一共有四个产品族，分布于三个不同的产品等级结构中。只要指明一个产品所处的产品族以及它所属的等级结构，就可以唯一的确定这个产品。

引进抽象工厂模式

所谓的抽象工厂是指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象。如果用图来描述的话，如下图：

 

二、 Abstract Factory模式的结构：

 

图中描述的东西用产品族描述如下：

 

抽象工厂（Abstract Factory）角色：担任这个角色的是工厂方法模式的核心，它是与应用系统商业逻辑无关的。

具体工厂（Concrete Factory）角色：这个角色直接在客户端的调用下创建产品的实例。这个角色含有选择合适的产品对象的逻辑，而这个逻辑是与应用系统的商业逻辑紧密相关的。

抽象产品（Abstract Product）角色：担任这个角色的类是工厂方法模式所创建的对象的父类，或它们共同拥有的接口。

具体产品（Concrete Product）角色：抽象工厂模式所创建的任何产品对象都是某一个具体产品类的实例。这是客户端最终需要的东西，其内部一定充满了应用系统的商业逻辑。

三、 程序举例：

该程序演示了抽象工厂的结构，本身不具有任何实际价值。

//  Abstract Factory pattern -- Structural example  
using  System;

//  "AbstractFactory"
abstract   class  AbstractFactory
{
  // Methods
  abstract public AbstractProductA CreateProductA();
  abstract public AbstractProductB CreateProductB();
}

//  "ConcreteFactory1"
class  ConcreteFactory1 : AbstractFactory
{
  // Methods
  override public AbstractProductA CreateProductA()
  {
    return new ProductA1();
  }
  override public AbstractProductB CreateProductB()
  {
    return new ProductB1();
  }
}

//  "ConcreteFactory2"
class  ConcreteFactory2 : AbstractFactory
{
  // Methods
  override public AbstractProductA CreateProductA()
  {
    return new ProductA2();
  }

  override public AbstractProductB CreateProductB()
  {
    return new ProductB2();
  }
}

//  "AbstractProductA"
abstract   class  AbstractProductA
{
}

//  "AbstractProductB"
abstract   class  AbstractProductB
{
  // Methods
  abstract public void Interact( AbstractProductA a );
}

//  "ProductA1"
class  ProductA1 : AbstractProductA
{
}

//  "ProductB1"
class  ProductB1 : AbstractProductB
{
  // Methods
  override public void Interact( AbstractProductA a )
  {
    Console.WriteLine( this + " interacts with " + a );
  }
}

//  "ProductA2"
class  ProductA2 : AbstractProductA
{
}

//  "ProductB2"
class  ProductB2 : AbstractProductB
{
  // Methods
  override public void Interact( AbstractProductA a )
  {
    Console.WriteLine( this + " interacts with " + a );
  }
}

//  "Client" - the interaction environment of the products
class  Environment
{
  // Fields
  private AbstractProductA AbstractProductA;
  private AbstractProductB AbstractProductB;

  // Constructors
  public Environment( AbstractFactory factory )
  {
    AbstractProductB = factory.CreateProductB();
    AbstractProductA = factory.CreateProductA();
  }
 
  // Methods
  public void Run()
  {
    AbstractProductB.Interact( AbstractProductA );
  }
}

/// 

/// ClientApp test environment
/// 

class  ClientApp
{
  public static void Main(string[] args)
  {
    AbstractFactory factory1 = new ConcreteFactory1();
    Environment e1 = new Environment( factory1 );
    e1.Run();

    AbstractFactory factory2 = new ConcreteFactory2();
    Environment e2 = new Environment( factory2 );
    e2.Run();
  }
}

 

四、 在什么情形下使用抽象工厂模式：

在以下情况下应当考虑使用抽象工厂模式：

• 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。
• 这个系统有多于一个的产品族，而系统只消费其中某一产品族。
• 同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。
• 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。
  
  

五、 抽象工厂的起源

据说最早的应用是用来创建在不同操作系统的视窗环境下都能够运行的系统。比如在Windows与Unix系统下都有视窗环境的构件，在每一个操作系统中，都有一个视窗构件组成的构件家族。我们可以通过一个抽象角色给出功能描述，而由具体子类给出不同操作系统下的具体实现，如图：

 

可以发现上面产品类图有两个产品等级结构，分别是Button与Text；同时有两个产品族：Unix产品族与Windows产品族。

 

系统对产品对象的创建要求由一个工厂的等级结构满足。其中有两个具体工厂角色，即UnixFactory和WinFactory。UnixFactory对象负责创建Unix产品族中的产品，而WinFactory负责创建Windows产品族中的产品。

 

显然一个系统只能够在某一个操作系统的视窗环境下运行，而不能同时在不同的操作系统上运行。所以，系统实际上只能消费属于同一个产品族的产品。

在现代的应用中，抽象工厂模式的使用范围已经大大扩大了，不再要求系统只能消费某一个产品族了。

六、 Abstract Factory模式在实际系统中的实现

Herbivore：草食动物
Carnivore：食肉动物
Bison：['baisn]，美洲或欧洲的野牛

下面实际代码演示了一个电脑游戏中创建不同动物的抽象工厂。尽管在不同大陆下动物物种是不一样的，但动物间的关系仍然保留了下来。

//  Abstract Factory pattern -- Real World example  
using  System;

//  "AbstractFactory"
abstract   class  ContinentFactory
{
  // Methods
  abstract public Herbivore CreateHerbivore();
  abstract public Carnivore CreateCarnivore();
}

//  "ConcreteFactory1"
class  AfricaFactory : ContinentFactory
{
  // Methods
  override public Herbivore CreateHerbivore()
  { return new Wildebeest(); }

  override public Carnivore CreateCarnivore()
  { return new Lion(); }
}

//  "ConcreteFactory2"
class  AmericaFactory : ContinentFactory
{
  // Methods
  override public Herbivore CreateHerbivore()
  { return new Bison(); }

  override public Carnivore CreateCarnivore()
  { return new Wolf(); }
}

//  "AbstractProductA"
abstract   class  Herbivore
{
}

//  "AbstractProductB"
abstract   class  Carnivore
{
  // Methods
  abstract public void Eat( Herbivore h );
}

//  "ProductA1"
class  Wildebeest : Herbivore
{
}

//  "ProductB1"
class  Lion : Carnivore
{
  // Methods
  override public void Eat( Herbivore h )
  {
    // eat wildebeest
    Console.WriteLine( this + " eats " + h );
  }
}

//  "ProductA2"
class  Bison : Herbivore
{
}

//  "ProductB2"
class  Wolf : Carnivore
{
  // Methods
  override public void Eat( Herbivore h )
  {
    // Eat bison
    Console.WriteLine( this + " eats " + h );
  }
}

//  "Client"
class  AnimalWorld
{
  // Fields
  private Herbivore herbivore;
  private Carnivore carnivore;

  // Constructors
  public AnimalWorld( ContinentFactory factory )
  {
    carnivore = factory.CreateCarnivore();
    herbivore = factory.CreateHerbivore();
  }

  // Methods
  public void RunFoodChain()
  { carnivore.Eat(herbivore); }
}

/// 

///  GameApp test class
/// 

class  GameApp
{
  public static void Main( string[] args )
  {
    // Create and run the Africa animal world
    ContinentFactory africa = new AfricaFactory();
    AnimalWorld world = new AnimalWorld( africa );
    world.RunFoodChain();

    // Create and run the America animal world
    ContinentFactory america = new AmericaFactory();
    world = new AnimalWorld( america );
    world.RunFoodChain();
  }
}

抽象工厂的另外一个例子：

如何设计抽象类工厂留作思考。

七、 "开放－封闭"原则

"开放－封闭"原则要求系统对扩展开放，对修改封闭。通过扩展达到增强其功能的目的。对于涉及到多个产品族与多个产品等级结构的系统，其功能增强包括两方面：

增加产品族：Abstract Factory很好的支持了"开放－封闭"原则。

增加新产品的等级结构：需要修改所有的工厂角色，没有很好支持"开放－封闭"原则。

综合起来，抽象工厂模式以一种倾斜的方式支持增加新的产品，它为新产品族的增加提供方便，而不能为新的产品等级结构的增加提供这样的方便。

---

参考文献：
阎宏，《Java与模式》，电子工业出版社
[美]James W. Cooper，《C#设计模式》，电子工业出版社
[美]Alan Shalloway  James R. Trott，《Design Patterns Explained》，中国电力出版社
[美]Robert C. Martin，《敏捷软件开发－原则、模式与实践》，清华大学出版社
[美]Don Box, Chris Sells，《.NET本质论 第1卷：公共语言运行库》，中国电力出版社

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

http://www.cnblogs.com/anlyren/archive/2008/01/31/abstract_factory.html

抽象工厂模式（Abstract Factory Pattern）

引入：
在前面介绍的两个创建型模式里面，我们解决的都是有关"new"的问题，用它们来避免显式指定类创建对象。我写的也非常简单易懂，相信看过的朋友们都应该对简单工厂模式、工厂方法模式的意图、所能解决的问题及适用情景有一定的了解了。但是若要达到灵活运用，什么时候用，怎样用合适还不是看一篇文章就能解决的问题。呵呵..这需要你对OO的理解程度，你的项目开发经验等等许多方面的积累。一起努力喔。。
好了，咱们言归正传，通过对这两个模式的了解，我们掌握一种思想，就是在创建一个对象时，需要把容易发生变化的地方给封装起来，来控制变化（哪里变化，封装哪里），以适应客户的变动，项目的扩展。但是，我们在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作，同时由于需求的变化，这“一系列相互依赖的对象”也要改变，如何应对这种变化呢？如何像简单工厂模式、工厂方法模式一样绕过常规的"new"，然后提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？可能有人会说，你也可以将这些对象一个一个通过工厂方法模式来解决呀？但是，我们试想，既然是一系列相互依赖的对象，它们是有联系的，每个对象都这样解决，你又如何来保证他们的联系呢？举一个例子：Windows桌面主题，当你更换一个桌面主题的时候，系统的开始按钮、任务栏、菜单栏、工具栏等等都变了，而且是一起变的，他们的色调都还很一致，难道类似这样的问题，怎么来解决呢？它的天敌就是抽象工厂模式。

意图：
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

参考者：
也就是该模式中的各个类或对象之间的关系：

• 抽象工厂（Abstract Factory)
  声明生成一系列抽象产品的方法
• 具体工厂（Concrete Factory）
  执行生成一系列抽象产品的方法，生成一系列具体的产品
• 抽象产品（Abstract Product）
  为这一系列的某一种产品声明接口
• 具体产品（Product）
  定义具体工厂生成的具体产品的对象，实现产品接口
• 客户（Client）
  我们的应用程序客户端（不要理解成人），使用抽象产品和抽象工厂生成对象。

 抽象工厂模式UML图


抽象工厂模式在生活中的实例
咱们继续拿怎么穿衣服来说明这个抽象工厂模式。
就拿你来说吧。工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。咱们假设一种情况(现实中是不存在的,要不然,没法进入共产主义了,但有利于说明抽象工厂模式)，在你的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用OO的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。

分析：
要好好去读上面那个实例，虽然有点绕嘴，其实只要用心去读，分清了抽象工厂模式的各个角色，对理解设计模式是非常重要的。理解头绪，然后接合简单工厂模式、工厂方法模式对工厂家族的了解，再加上抽象工厂模式的意图，头脑中差不多有一个雏型了吧。好了，咱们一起来分析一下。。
先把各个角色揪出来。
抽象工厂：虚拟的衣柜，它只是个概念而已。在项目中可能是一个接口或抽象类，定义规则，取出上衣，裤子。
具体工厂：具体的存在的衣柜，它用于存放某一种成套的衣服，换句话说，这种成套的衣服都是从这个衣柜中取出的。在项
              目中继承于抽象工厂，实现抽象工厂中的方法，取出具体产品，某一件上衣，某一条裤子。
抽象产品：虚拟的衣服，也只是个概念。在项目中可能是多个接口或抽象类，定义规则，有什么特性，起什么作用。
具体产品：具体的实际存在的产品，它指的就是用于组装成某一套衣服的某一件上衣或裤子。它继承自某一个抽象产品。实
              现抽象产品中制定的规则，特性。
它们之间怎么联系呢？客户在用的时候，依赖的又是什么呢？
客户在要的时候，首先要说出你要的什么系列的衣服，然后根据它的要求生成一个具体工厂的实例，剩下的工作就都是这个倒霉的具体工厂了，它会根据自己的实现生成一个上衣，生成一个裤子，然后把它交给客户。客户在这一过程中并不知道具体工厂都做了什么。也就是说，客户只依赖于抽象工厂和抽象产品了。在初始化的时候会用到一次具体工厂类名，我们根据.NET特有的反射机制又可以把这个在客户端唯一的具体的非抽象类放到一个应用程序配置文件中，防止它变化。
这就符合了设计模式中的“开放--封闭”原则，依赖倒转原则，里氏代换原则等等。

具体代码如下：
抽象工厂角色：

 1 namespace  AbstractFactory
 2 {
 3    //抽象工厂类,
 4    public abstract class AbstractClothes
 5    {
 6        //抽象方法:创建一个上衣
 7        abstract public AbstractCoat CreateCoat();
 8        //抽象方法:创建一个裤子
 9        abstract public AbstractTrousers CreateTrousers();
10    }
11}
12

抽象产品角色：

 1 namespace  AbstractFactory
 2 {
 3    /// 

 4    /// 抽象产品----上衣抽象类
 5    /// 

 6    public abstract class AbstractCoat
 7    {
 8        //性别属性
 9        public abstract bool Sex
10        {
11            get;
12        }
13
14        //样式属性
15        public abstract string Style
16        {
17            get;
18        }
19    }
20
21    /// 

22    /// 抽象产品----裤子抽象类
23    /// 

24    public abstract class AbstractTrousers
25    {
26        //性别属性
27        public abstract bool Sex
28        {
29            get;
30        }
31
32        //样式属性
33        public abstract string Style
34        {
35            get;
36        }
37    }
38}
39

具体工厂角色：

 1 namespace  AbstractFactory
 2 {
 3    /// 

 4    ///时尚男装 
 5    /// 

 6    public class FashionManClothes:AbstractClothes
 7    {
 8        public override AbstractFactory.AbstractCoat CreateCoat()
 9        {
10            return new CoatA();
11        }
12
13        public override AbstractTrousers CreateTrousers()
14        {
15            return new TrousersA();
16        }
17    }
18
19    /// 

20    /// 时尚女装
21    /// 

22    public class FashionWomanClothes : AbstractClothes
23    {
24        public override AbstractCoat CreateCoat()
25        {
26            return new CoatB();
27            //throw new Exception("The method or operation is not implemented.");
28        }
29        public override AbstractTrousers CreateTrousers()
30        {
31            return new TrousersB();
32            //throw new Exception("The method or operation is not implemented.");
33        }
34    }
35}

具体产品角色：（注意：我并没有把所有的具体产品类都列出来，由于简单，可以推想出剩余的产品类，详见附件）

 1 namespace  AbstractFactory
 2 {
 3    /// 

 4    /// 时尚男性上衣
 5    /// 

 6    public class CoatA:AbstractFactory.AbstractCoat
 7    {
 8        private bool sex = true;
 9        private string style = "时尚";
10        /// 

11        /// 重写基类的Sex属性
12        /// 

13        public override bool Sex
14        {
15            get
16            {
17                return sex;
18            }            
19        }
20        
21        /// 

22        /// 重写基类的Style属性
23        /// 

24        public override string Style
25        {
26            get
27            {
28                return style;
29            }            
30        }
31    }
32
33    /// 

34    /// 时尚男性裤子
35    /// 

36    public class TrousersA : AbstractTrousers
37    {
38        private bool sex = true;
39        private string style = "时尚";
40        public override bool Sex
41        {
42            get
43            {
44                return sex;
45            }
46        }
47        public override string Style
48        {
49            get
50            {
51                return style;
52            }
53        }
54    }
55}

客户端代码：

 1 namespace  AbstractFactory
 2 {
 3    /// 

 4    /// 创建衣服类
 5    /// 

 6    public class CreateClothes
 7    {
 8        private AbstractCoat myCoat;
 9        private AbstractTrousers myTrousers;
10        public CreateClothes(AbstractClothes clothes)
11        {
12            myCoat = clothes.CreateCoat();
13            myTrousers = clothes.CreateTrousers();
14        }
15
16        public void ShowMyClothes()
17        {
18            Console.WriteLine("My Clothes:");
19            string sex= myCoat.Sex ? "男" : "女";
20            //Console.WriteLine("Coat:{0} {1}", myCoat.Sex ? "男" : "女", myCoat.Style);
21            Console.WriteLine("Coat:{0} {1}", sex, myCoat.Style);
22            sex=myTrousers.Sex?"男":"女";
23            Console.WriteLine("Trousers:{0} {1}", sex, myTrousers.Style);
24        }
25    }  
26
27
28    public class Client
29    {
30        static void Main(string[] args)
31        {
32            //创建一个工厂类的实例   
33            string assemblyName = ConfigurationManager.AppSettings["assemblyName"];
34            string fullTypeName =string.Concat( ConfigurationManager.AppSettings["nameSpaceName"] ,".", ConfigurationManager.AppSettings["typename"]);
35
36            AbstractClothes factory = (AbstractClothes)Assembly.Load(assemblyName).CreateInstance(fullTypeName);
37            CreateClothes clothes = new CreateClothes(factory);
38            clothes.ShowMyClothes();
39            Console.Read();
40        }        
41    }
42}
43

app.config文件

1 < configuration >
2    < appSettings >
3     
4      < add key = " assemblyName "  value = " ConcreteFactory " />
5      < add key = " nameSpaceName "  value = " AbstractFactory " />
6      < add key = " typename "  value = " FashionManClothes " />
7    appSettings >
8 configuration >

这样，代码就完成了。

小结一下：
抽象工厂模式堪称gof23种设计模式精典模式之一，它能够解决诸如：通过显示指定类创建对象，紧耦合，对对象表示或实现的依赖等等一些问题，有关设计模式的设计原则，所能解决的问题，详见OO与设计模式的原则、目标 。
抽象工厂模式适用于对“一系列相互依赖的对象”的创建工作，这些对象是相互依赖的，是有联系的。如果仅为一个对象的创建则用简单工厂模式或工厂方法模式完全可以实现，没有必要用抽象工厂模式。
由于抽象工厂模式的客户端只依赖于抽象工厂，抽象产品，在初始化过程中仅用到一次具体工厂我们又把它放在了app.config中了，完全依赖接口，这样不仅在系统的扩展性方面好，而且可以提高团队开发效率。两个团队只要彼此了解定义的接口，抽象类，可以并行开发。举个例子，就拿博客园来说吧，我们在用自己的博客空间时，可以随时的换皮肤，这个换皮肤是不是典型的抽象工厂模式吗？如果是，它的各个角色又是什么呢？我认为是的。换一下皮肤，你博客页面上的各个样式都变了，而且这里各个样式都同属于你选定的这一个皮肤。而每个样式都又是独立的，它们组合起来就成了一款皮肤。我们来揪出来各个角色。
抽象工厂：皮肤
抽象产品：样式
具体工厂：某一款皮肤，皮肤名即为具体工厂的类名
具体产品：某一个样式。
虽然不存在这样的接口与类，但是它确实是抽象工厂模式的一个应用。抽象工厂制定都有哪些样式名，而具体工厂来实现这些样式名中的样式，而具体工厂中用到的各个样式都是一个具体产品。这也是我的理解，如兄弟们有不同的见解，欢迎发表意见，共同探讨。
确定过各个角色之后，就可以说一下为什么提高效率了。不论dudu在设计博客园时用什么工具或语言，它与泸江博客只要约定好所有用到的样式名就可以了。而泸江博客就可以根据要求单独去做每一款皮肤了。

优点：

• 隔离了具体类的生成，客户不需要知道怎样生成了每一个具体产品，什么时间生成的。它将客户与具体的类分离，依赖于抽象类，耦合性低。
• 一个产品族中的多个对象被设计成一起工作，它能够保证客户端始终只使用一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是非常实用的一种设计模式。 
• 它有利于更换产品系列，由于客户端只依赖于抽象类，具体类也被写到应用程序配置文件中，更换产品系列时，只须更改一下具体工厂名就行了。

缺点：

• 难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。

应用情景：

• 同一个产品族的产品在一起使用时，而且它们之间是相互依赖的，不可分离
• 系统需要由相互关联的多个对象来构成
• 你想提供一组对象而不显示它们的实现过程，只显示它们的接口
• 系统不应当依赖某一些具体产品类。

应用场景举例：

• 游戏开发中的多风格系列场景
• 系统更改皮肤
• 支持多种观感标准的用户界面工具箱（Kit）。

参考资料

• 《深入浅出设计模式(C#/Java版) 》 清华大学出版社 
• MSDN Webcast  C#面向对象设计模式纵横谈 李建忠老师

源程序下载：
            http://files.cnblogs.com/anlyren/AbstractFactory.rar

©2007 renly
原创作品，欢迎转载，转载请注明来自博客园，留此信息。

.NET设计模式（3）：抽象工厂模式（Abstract Factory）

http://www.cnblogs.com/Terrylee/archive/2005/12/13/295965.html

抽象工厂模式（Abstract Factory）

——探索设计模式系列之三

Terrylee，2005年12月12日

概述

在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。

意图

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

模型图

逻辑模型：

物理模型：

生活中的例子

抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。这种模式可以汽车制造厂所使用的金属冲压设备中找到。这种冲压设备可以制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改变冲压盘，这个机械产生的具体类可以在三分钟内改变。

抽象工厂之新解

虚拟案例

中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。

员工的工资 = (基本工资 + 奖金 - 个人所得税)。这是一个放之四海皆准的运算法则。

为了简化系统，我们假设员工基本工资总是4000美金。

中国企业奖金和个人所得税的计算规则是:

         奖金 = 基本工资(4000) * 10%

         个人所得税 = (基本工资 + 奖金) * 40%

我们现在要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。

案例分析

奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)。

工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。

工资的计算作为业务规则的前端(或者客户端Client)将提供给最终使用该系统的用户(财务人员)使用。

针对中国企业为系统建模

根据上面的分析，为Softo系统建模如下：

 

则业务规则Service类的代码如下：

 1 using  System;
 2
 3 namespace  ChineseSalary
 4 {
 5    /// 

 6    /// 公用的常量
 7    /// 

 8    public class Constant
 9    {
10        public static double BASE_SALARY = 4000;
11    }
12}

 1 using  System;
 2
 3 namespace  ChineseSalary
 4 {
 5    /// 

 6    /// 计算中国个人奖金
 7    /// 

 8    public class ChineseBonus
 9    {
10        public double Calculate()
11        {
12            return Constant.BASE_SALARY * 0.1;
13        }
14    }
15}
16

客户端的调用代码：

 1 using  System;
 2
 3 namespace  ChineseSalary
 4 {    
 5    /// 

 6    /// 计算中国个人所得税
 7    /// 

 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类的代码如下：

 1 using  System;
 2
 3 namespace  AmericanSalary
 4 {
 5    /// 

 6    /// 公用的常量
 7    /// 

 8    public class Constant
 9    {
10        public static double BASE_SALARY = 4000;
11    }
12}
13

 1 using  System;
 2
 3 namespace  AmericanSalary
 4 {
 5    /// 

 6    /// 计算美国个人奖金
 7    /// 

 8    public class AmericanBonus
 9    {
10        public double Calculate()
11        {
12            return Constant.BASE_SALARY * 0.1;
13        }
14    }
15}
16

 1 using  System;
 2
 3 namespace  AmericanSalary
 4 {    
 5    /// 

 6    /// 计算美国个人所得税
 7    /// 

 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
 2 using  System;
 3
 4 namespace  AmericanSalary
 5 {
 6    /// 

 7    /// 客户端程序调用
 8    /// 

 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
 2 using  System;
 3
 4 namespace  InterfaceSalary
 5 {
 6    /// 

 7    /// 客户端程序调用
 8    /// 

 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)，代码如下：

 1 using  System;
 2
 3 namespace  FactorySalary
 4 {
 5    /// 

 6    /// Factory类
 7    /// 

 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
 2 using  System;
 3
 4 namespace  FactorySalary
 5 {
 6    /// 

 7    /// 客户端程序调用
 8    /// 

 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类，修改结果如下：

 1 using  System;
 2
 3 namespace  FactorySalary
 4 {
 5    /// 

 6    /// Factory类
 7    /// 

 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)动态地判断应该实例化哪个工厂类，这样，我们就把移植工作转移到了对配置文件的修改。修改后的模型和代码：

 

抽象工厂类的代码如下：

 1 using  System;
 2 using  System.Reflection;
 3  
 4 namespace  AbstractFactory
 5 {
 6     /// 

 7     /// AbstractFactory类
 8     /// 

 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中发射机制代替，修改如下：

 1 using  System;
 2 using  System.Reflection;
 3
 4 namespace  AbstractFactory
 5 {
 6    /// 

 7    /// AbstractFactory类
 8    /// 

 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         抽象工厂将产品对象的创建延迟到它的具体工厂的子类。

l         如果没有应对“多系列对象创建”的需求变化，则没有必要使用抽象工厂模式，这时候使用简单的静态工厂完全可以。

l         系列对象指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。

l         抽象工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化。

l         通常在运行时刻创建一个具体工厂类的实例，这一具体工厂的创建具有特定实现的产品对象，为创建不同的产品对象，客户应使用不同的具体工厂。

l         把工厂作为单件，一个应用中一般每个产品系列只需一个具体工厂的实例，因此，工厂通常最好实现为一个单件模式。

l         创建产品，抽象工厂仅声明一个创建产品的接口，真正创建产品是由具体产品类创建的，最通常的一个办法是为每一个产品定义一个工厂方法，一个具体的工厂将为每个产品重定义该工厂方法以指定产品，虽然这样的实现很简单，但它确要求每个产品系列都要有一个新的具体工厂子类，即使这些产品系列的差别很小。

优点

l         分离了具体的类。抽象工厂模式帮助你控制一个应用创建的对象的类，因为一个工厂封装创建产品对象的责任和过程。它将客户和类的实现分离，客户通过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，它们不出现在客户代码中。

l         它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。

l         它有利于产品的一致性。当一个系列的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要，而抽象工厂很容易实现这一点。

缺点

l         难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。

适用性

在以下情况下应当考虑使用抽象工厂模式：

l         一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。

l         这个系统有多于一个的产品族，而系统只消费其中某一产品族。

l         同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。

l         系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。

应用场景

l         支持多种观感标准的用户界面工具箱（Kit）。

l         游戏开发中的多风格系列场景，比如道路，房屋，管道等。

l         ……

总结

总之，抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，运用抽象工厂模式的关键点在于应对“多系列对象创建”的需求变化。一句话，学会了抽象工厂模式，你将理解OOP的精华：面向接口编程。

 _____________________________________________________________________________

源程序下载：/Files/Terrylee/AbstractFactory.rar

参考文献

http://blog.dreambrook.com

《Java与模式》

《设计模式》

《Design  Patterns  Explained》

作者： TerryLee
出处： http://terrylee.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。