学习笔记系列之NET设计模式(2):抽象工厂(Abstract Factory)

动机（Motivation）

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

意图（Intent）
提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。
——《设计模式》GoF

抽象工厂模式可以向客户端提供一个接口，使得客户端在不必指定产品的具体类型的情况下，创建多个产品族中的产品对象。

适用性

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

结构（Structure）

 代码实现

 

 1      public   abstract   class  ProductA
 2      {
 3        
 4    }
 5
 6      public   class  ProductA1 : ProductA
 7      {
 8
 9    }
10
11      public   class  ProductA2 : ProductA
12      {
13
14    }
15
16      public   abstract   class  ProductB
17      {
18
19    }
20
21      public   class  ProductB1 : ProductB
22      {
23
24    }
25
26      public   class  ProductB2 : ProductB
27      {
28
29    }

 

 1 public   abstract   class  Creator
 2      {
 3    }
 4
 5      public   abstract   class  ConcreteCreatorA : Creator
 6      {
 7        public ProductA FactoryA()
 8        {
 9            return new ProductA1();
10        }
11
12        public ProductB FactoryB()
13        {
14            return new ProductB1();
15        }
16    }
17
18      public   abstract   class  ConcreteCreatorB : Creator
19      {
20        public ProductA FactoryA()
21        {
22            return new ProductA2();
23        }
24
25        public ProductB FactoryB()
26        {
27            return new ProductB2();
28        }
29    }

Abstract Factory模式的几个要点
? 如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的静态工厂完全可以。
? “系列对象”指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。
? Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。
? Abstract Factory模式经常和Factory Method模式共同组合来应对“对象创建”的需求变化。