学习笔记系列之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    }

    public class ProductA2 : ProductA
    {

    }

    public abstract class ProductB
    {

    }

    public class ProductB1 : ProductB
    {

    }

    public class ProductB2 : ProductB
    {

    }

 

 1public abstract class Creator
 2    {
 3    }
 4
 5    public abstract class ConcreteCreatorA : Creator
 6    {
 7        public ProductA FactoryA()
 8        {
 9            return new ProductA1();
        }

        public ProductB FactoryB()
        {
            return new ProductB1();
        }
    }

    public abstract class ConcreteCreatorB : Creator
    {
        public ProductA FactoryA()
        {
            return new ProductA2();
        }

        public ProductB FactoryB()
        {
            return new ProductB2();
        }
    }

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