.NET设计模式之简单工厂模式 （转载）

.NET设计模式(1): 简单工厂模式

文章来源：http://www.cnblogs.com/anlyren/archive/2008/01/25/simple_Factory_Pattern.html

最近一直在看设计模式，想把自己的学习笔记与大家分享一下，如果能帮助大家的话，我会非常高兴，同时也欢迎大家指出里面的不足。园子里其实关于此类文章已经很多了，如果dudu感觉放在首页欠妥的话，可以调一下。

简单工厂模式（Simple Factory Pattern）

介绍：简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导，所以我想有必要把它作为第一个讲一下。

引入：
我们在编程的时候，每当"new"一个对象之后，这个对象就依赖于这个类了。如果在后期的维护过程中由于某些原因需要修改一下这个类，则唯一的做法就是打开源代码，进行修改，修改所有与这个对象有关的操作。这对我们是非常不利的。
问题出来了：对象不能应对“具体实例化类型”的变化
解决思路：套用一下李建忠李老师的话，封装变化点，哪里变化，封装哪里。在这个例子中，要实例化的类变了，就将实例化这个操作封装起来，我们可以把"new"这个操作移交一个具体的类，由它去负责根据我们的条件创建具体类的实例，也就是下面要说的“简单工厂模式”。

定义：
专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类或接口。简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。

意图：
提供一个类，由它负责根据一定的条件创建某一具体类的实例

参与者：

• 工厂角色（Creator）
  是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。
• 抽象产品角色（Product）
  是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。
• 具体产品角色（Concrete Product）
  继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。

UML图：


现实生活中例子：
每次参加不同的聚会或者与不同的人见面，可能穿的衣服是不一样的，比如，你今天上午要与你的一个新客户见面，你可能会对你的老婆说：老婆，给拿件商务装（参数），我要去见我的一个客户，你老婆（工厂类）接到你的请求（商务装参数）后，从衣柜中取出一件商务装（具体产品），交给你。整个过程就完成了。

分析：
你可能根据不同的条件，要的衣服是不一样的，但要的衣服都是已经在你的衣柜中存在的。并且，每件上衣它们都属于同一种抽象，即它们可以从一个抽象类或接口中继承，这此衣服各自都有一定特征，这些都是条件。然后你要的时候，就可以向你老婆说一种特征，她就会根据这个特征为你服务了。这就是典型的简单工厂模式的应用。
 抽象产品类代码

1    /// <summary>
2    /// 抽象产品类:上衣
3    /// </summary>
4    public interface ICoat
5    {
6        void GetYourCoat();
7    }

 

非常简单，是吧？这里我只是举一个仅仅能说明问题的例子，在具体的项目中，可能是很复杂的哦。。

具体产品类代码

 1namespace SimpleFactory
 2{
 3    /// <summary>
 4    /// 具体产品类：商务上衣
 5    /// </summary>
 6    public class BusinessCoat:ICoat
 7    {
 8        public void GetYourCoat()
 9        {
10            Console.WriteLine("商务上衣");
11        }
12    }
13
14    /// <summary>
15    /// 具体产品类：时尚上衣
16    /// </summary>
17    public class FashionCoat : ICoat
18    {
19        /// <summary>
20        /// 实现ICoat中定义的方法
21        /// </summary>
22        /// <returns></returns>
23        public void GetYourCoat()
24        {
25            Console.WriteLine("时尚上衣");
26        }
27    }
28}

简单工厂模式中最核心的部分：工厂类

 1namespace SimpleFactory
 2{
 3    /// <summary>
 4    /// 简单工厂模式中的核心部分:工厂类
 5    /// </summary>
 6    public class Factory
 7    {
 8        public ICoat CreateCoat(string styleName)
 9        {
10            switch (styleName.Trim().ToLower())
11            {
12                case "business":
13                    return new BusinessCoat();
14                case "fashion":
15                    return new FashionCoat();
16                default :
17                    throw new Exception("还没有你要的那种衣服");
18            }
19        }
20    }
21}

再看一下客户在调用的时候的代码

 1 /// <summary>
 2    /// 客户类
 3    /// </summary>
 4    class Client
 5    {
 6        static void Main(string[] args)
 7        {
 8            ICoat food;
 9            try
10            {
11                Factory factory = new Factory();
12
13                Console.Write("我要的是时尚上衣\t");
14                food = factory.CreateCoat("fashion");
15                food.GetYourCoat();
16
17            }
18            catch (Exception ex)
19            {
20                Console.WriteLine(ex.Message);
21            }
22        }
23    }

到这里，代码就完成了。
在客户端的代码中有我们就可以根据具体的参数，返回我们希望返回的对象，将"new"操作推迟到工厂类中实现。
这里，参数我直接写上了，我们其实可以将这个参数写到一个xml文件中，如app.config文件中，动态的读出来，需要穿另外一种衣服了，只需要打开app.config文件，修改里面的值就行了，不需要项目重新编译。这样这个小程序就能够适应一定的变化了（在上传上去的代码中我会修改一下）。其实它也是设计模式正要解决的问题，在不修改代码的情况下，使项目能够适应一定的客户需求变化。注意，是一定的，并非全部。

优点：

• 简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过它，外界可以从直接创建具体产品对  象的尴尬局面中摆脱出来。
• 外界与具体类隔离开来，偶合性低。
• 明确区分了各自的职责和权力，有利于整个软件体系结构的优化。

缺点：

• 工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则 
• 虽然简单工厂模式能够适应一定的变化，但是它所能解决的问题是远远有限的。它所能创建的类只能是事先教考虑到的，如果需要添加新的类，则就需要改变工厂类了。（这个问题在下一个工厂方法模式将得到很好的解决）

应用情景

• 工厂类负责创建的对象比较少 
• 客户只知道传入了工厂类的参数，对于始何创建对象（逻辑）不关心 

参考资料

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

源程序下载：/Files/anlyren/SimpleFactory.rar

 

.NET设计模式(2): 工厂方法模式

工厂方法模式（Factory Method Pattern）

介绍：
在简单工厂模式中，我们提到，工厂方法模式是简单工厂模式的一个延伸，它属于Gof23中设计模式的创建型设计模式。它解决的仍然是软件设计中与创建对象有关的问题。它可以更好的处理客户的需求变化。

引入
我们继续来说"new"的问题，我们在简单工厂模式中，将实例化对象的工作推迟到了专门负责创建对象的工厂类中，这样，在我们事先预知的情况下，可以根据我们的需要动态创建产品类。但是，我们的预知是有限的，客户的变化可能是无限的。所以，就出现了问题，一旦客户的变化超越了我们的预知，我们就必须修改我们的源代码了。这是设计模式所不允许的，怎么办呢？工厂方法模式正是解决此类问题的。
问题：具体工厂类的创建工作不能满足我们的要求了，创建的工作变化了
解决思路：哪里变化，封装哪里。把具体工厂封装起来。

定义
工厂方法模式又称为工厂模式，也叫虚拟构造器（Virtual Constructor）模式或者多态工厂模式（Polymorphic Factory）,在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化（创建）哪一个类。

意图
定义一个用户创建对象的接口，让子类决定实例化哪一个类，工厂方法模式使一个类的实例化延迟到其子类。

参与者

• 抽象产品角色（Product）
  定义产品的接口
• 具体产品角色（ConcreteProduct）
  实现接口Product的具体产品类
• 抽象工厂角色（Creator）
  声明工厂方法（FactoryMethod），返回一个产品
• 真实的工厂（ConcreteCreator）
  实现FactoryMethod工厂方法，由客户调用，返回一个产品的实例

工厂方法模式UML图


现实生活中的例子
为了方便大家理解，我仍然举穿衣服方面的一个例子。这个例子与简单工厂模式中的那个例子有些不同。
据说清朝有个皇帝穿衣非常的奢侈，每种衣服（具体产品类）由一宫女（具体工厂类）专门负责，这样一来，每增加一种衣服（具体产品类），就要多出一个宫女（具体工厂类），但是他们各负其责，互不影响。皇帝之所以这样做，是因为针对穿衣服这件事来说，可扩展性是非常强的（）。

分析
实现的功能：可以根据皇帝的要求，动态的创建（由宫女去拿）已存在的具体产品（衣服），如果皇帝的要求太苛刻，这种衣服还没有，只需要增加一个宫女，一个衣服就能够满足他的要求了。每个宫女只负责一种衣服（高内聚），要增加一种衣服，对于以前的所有宫女与衣服来说，都不会受到影响（设计模式中所期望的）。说到这里，是不是明白了工厂方法模式所能解决的问题及其应用了？呵呵。。你一定在想，比简单工厂模式灵活性高吧。。

抽象工厂角色代码

 1namespace FactoryMethod
 2{
 3    /**//// <summary>
 4    /// 抽象工厂类,定义产品的接口
 5    /// </summary>
 6    public interface IFactory
 7    {
 8        ICoat CreateCoat();
 9    }
10}

抽象产品角色代码

 1namespace FactoryMethod
 2{
 3    /**//// <summary>
 4    /// 抽象产品类
 5    /// </summary>
 6    public interface ICoat
 7    {
 8        void ShowCoat();
 9    }
10}

具体工厂角色代码

 1namespace FactoryMethod
 2{
 3    /**//// <summary>
 4    /// 具体工厂类:用于创建商务上衣类
 5    /// </summary>
 6    public class BusinessFactory:IFactory
 7    {        
 8        public ICoat CreateCoat()
 9        {
10            return new BusinessCoat();
11        }
12    }
13
14    /**//// <summary>
15    /// 具体工厂类,用于创建时尚上衣
16    /// </summary>
17    public class FashionFactory : IFactory
18    {
19        public ICoat CreateCoat()
20        {
21            return new FashionCoat();
22        }
23    }
24}

具体产品角色代码

 1namespace FactoryMethod
 2{
 3    /**//// <summary>
 4    /// 具体产品类,商务上衣类
 5    /// </summary>
 6    public class BusinessCoat:ICoat
 7    {
 8        public void ShowCoat()
 9        {
10            Console.WriteLine("这件是商务上衣");
11        }
12    }
13
14    /**//// <summary>
15    /// 具体产品类,时尚上衣类
16    /// </summary>
17    public class FashionCoat : ICoat
18    {
19        public void ShowCoat()
20        {
21            Console.WriteLine("这件是时尚上衣");
22        }
23    }
24}
25

客户端代码

 1namespace FactoryMethod
 2{
 3    /**//// <summary>
 4    /// 客户端代码
 5    /// </summary>
 6    class Client
 7    {
 8        static void Main(string[] args)
 9        {
10            //为了方便以后修改,将工厂类的类名写在应用程序配置文件中
11            string factoryName = ConfigurationManager.AppSettings["FactoryName"];
12          
13            IFactory factory = (IFactory)Assembly.Load("ConcreteFactory").CreateInstance("FactoryMethod." + factoryName);
14            
15            ICoat coat = factory.CreateCoat();
16            //显示你要的上衣
17            coat.ShowCoat();
18        }
19    }
20}

客户端代码需要注意的两个地方：
1，把具体工厂类类名称写在了应用程序配置文件中，方便修改
2，用到了反射，利用.NET提供的反射可以根据类名来创建它的实例，非常方便


由反射想到的：
下面这一段内容不是计划要写的。
如果在具体工厂中，每次new的对象都是一个，而且这些类是继承自抽象产品接口的，那么我们用简单工厂模式也可以实现动态的增加具体产品类。这样来做，在简单工厂模式中最核心的部分----工厂类不要根据传来的条件去动态创建产品类，利用反射机制去创建。把要实例化的类名放在应用程序配置文件中，呵呵。。这样利用.NET特有的反射就可以用简单工厂模式解决更多的问题了，工厂方法模式的一部分问题也是可以通过“这样的简单工厂模式”解决的，在需要增加具体产品类时，不用增加具体工厂，是不是简单一些呀。下去试一下。。。

优点：

• 基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象。而且如何创建一个具体产品的细节完全封装在具体工厂内部，符合高内聚，低耦合。
• 在系统中加入新产品时，无需修改抽象工厂和抽象产品提供的接口，无需修改客户端，也无需修改其他的具体工厂和具体产品，很好的利用了封装和委托。

缺点：

• 在添加新产品时，需要编写新的具体产品类（其实这不算一个缺点，因为这是不可避免的），要增加与之对应的具体工厂类。

应用情景：

• 类不知道自己要创建哪一个对象时
• 类用它的子类来指定创建哪个对象
• 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候  

工厂方法模式在ASP.NET HTTP通道中的应用，TerryLee在他的那篇文件中写的非常好，推荐去看一下。

参考资料

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

源程序下载：
            https://files.cnblogs.com/anlyren/FactoryMethod.rar

 

 

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

抽象工厂模式（Abstract Factory Pattern）

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

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

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

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

 抽象工厂模式UML图


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

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

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

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

抽象产品角色：

 1namespace AbstractFactory
 2{
 3    /**//// <summary>
 4    /// 抽象产品----上衣抽象类
 5    /// </summary>
 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    /**//// <summary>
22    /// 抽象产品----裤子抽象类
23    /// </summary>
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

具体工厂角色：

 1namespace AbstractFactory
 2{
 3    /**//// <summary>
 4    ///时尚男装 
 5    /// </summary>
 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    /**//// <summary>
20    /// 时尚女装
21    /// </summary>
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}

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

 

 1namespace AbstractFactory
 2{
 3    /**//// <summary>
 4    /// 时尚男性上衣
 5    /// </summary>
 6    public class CoatA:AbstractFactory.AbstractCoat
 7    {
 8        private bool sex = true;
 9        private string style = "时尚";
10        /**//// <summary>
11        /// 重写基类的Sex属性
12        /// </summary>
13        public override bool Sex
14        {
15            get
16            {
17                return sex;
18            }            
19        }
20        
21        /**//// <summary>
22        /// 重写基类的Style属性
23        /// </summary>
24        public override string Style
25        {
26            get
27            {
28                return style;
29            }            
30        }
31    }
32
33    /**//// <summary>
34    /// 时尚男性裤子
35    /// </summary>
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}

客户端代码：

 1namespace AbstractFactory
 2{
 3    /**//// <summary>
 4    /// 创建衣服类
 5    /// </summary>
 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    <!--一般情况下只需改第三个"typename"就行了,具体工厂类    -->
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#面向对象设计模式纵横谈 李建忠老师

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