设计模式（04）：创建型模式(三) 抽象工厂模式（Abstract Factory）

一、动机（Motivation）

在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。

如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？

二、意图（Intent）

提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。

三、结构（Structure）

image

ProductA1和ProductB1是一个系列，ProductA2和ProductB2是另一个系列。ConcreteFactory1是创建系列1的工厂方法，ConcreteFactory2是创建系列2的工厂方法。客户程序Client只依赖了AbstractFactory和AbstractProductA、AbstractProductB，也就是客户程序不依赖于具体实现，而是只依赖与抽象类。

如果现在需要创建一个系列3运用到客户程序，我们只需要再写一个系列3的工厂，继承自AbstractFactory，这个工厂提供了2个实现：

CreateProductA();

CreateProductB();

它们分别返回ProductA3（继承自AbstractProductA）、ProductB3（继承自AbstractProductB）。

也就是说，如果新增了系列3，Client程序可以完全不用改动，可能只需要改一些配置文件，增加一些新dll就可以应对变化。

四、模式的组成

      可以看出，在抽象工厂模式的结构图有以下角色：

（1）、抽象产品类角色（AbstractProduct）：为抽象工厂中相互依赖的每种产品定义抽象接口对象，也可以这样说，有几种产品，就要声明几个抽象角色，每一个抽象产品角色和一种具体的产品相匹配。
（2）、具体产品类（ConcreteProduct）：具体产品类实现了抽象产品类，是针对某个具体产品的实现的类型。
（3）、抽象工厂类角色（Abstract Factory）：定义了创建一组相互依赖的产品对象的接口操作，每种操作和每种产品一一对应。
（4）、具体工厂类角色（ConcreteFactory）：实现抽象类里面的所有抽象接口操作，可以创建某系列具体的产品，这些具体的产品是“抽象产品类角色”的子类。

五、抽象工厂的具体代码实现

作为长子的我，希望能有一套欧式风格的房子，再加上田园风光，此生足矣。我弟弟就不一样了，他想要一套现代样式的房子，如果兄弟姊妹再多年一点，那就有更多的要求了。由于房子由房顶、地板、窗户和房门组成，其他组件暂时省略，有这么多套房子要建设，每套房子的房顶、地板、窗户和房门都是一个体系的，那就让我们看看如何使用【抽象工厂】模式来实现不同房屋的建造。

//抽象道路
public abstract class Road
{
}

//抽象房屋
public abstract class Building
{
}

//现代风格道路
public class ModernRoad : Road
{
}

//现代风格房屋
public class ModernBuilding : Building
{
}

//古典风格道路
public class ClassicRoad : Road
{
}

//古典风格房屋
public class ClassicBuilding : Building
{
}

//抽象工厂
public abstract class FacilitiesFactory
{
    public abstract Road CreateRoad();
    public abstract Building CreateBuilding();
}

//现代风格
public class ModernFacilitiesFactory : FacilitiesFactory
{
    public override Road CreateRoad()
    {
        return new ModernRoad();
    }

    public override Building CreateBuilding()
    {
        return new ModernBuilding();
    }
}

//古典风格
public class ClassicFacilitiesFactory : FacilitiesFactory
{
    public override Road CreateRoad()
    {
        return new ClassicRoad();
    }

    public override Building CreateBuilding()
    {
        return new ClassicBuilding();
    }
}

客户程序：

可以看出，客户程序依赖的全部是抽象类，在客户程序代码中没有出现过任何具体的实现类。因为在系列需要变化的时候，是不需要改变抽象类的，只是增加一个抽象类的实现而已，又由于客户程序只依赖于抽象，所以系列变化的时候客户程序完全无需变化。

internal class GameManager
{

    private FacilitiesFactory facilitiesFactory;
    private Road road;
    private Building building;

    public GameManager(FacilitiesFactory facilitiesFactory)
    {
        this.facilitiesFactory = facilitiesFactory;
    }

    public void BuildGameFacilities()
    {
        road = facilitiesFactory.CreateRoad();
        building = facilitiesFactory.CreateBuilding();
    }

    public void Run()
    {
        Console.WriteLine(road);
        Console.WriteLine(building);
    }
}

应用到具体程序（现代风格）：

可以看出，风格由Modern改变为Classic的时候，我们封装好的GameManager客户程序没有改变，这就是我们想要的结果。GameManager的逻辑非常复杂，现在它的稳定，能够大大方便我们的工作。

GameManager g = new GameManager(new ModernFacilitiesFactory());
g.BuildGameFacilities();
g.Run();

改造

第一种改造

就是在系列对象不发生系列添加的情况下，使用配置文件来进行例子中场景风格的替换。添加一个App.config文件，在其中加入风格设置的字段。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
         <appSettings>
              <add key="factoryName" value="ModernFacilitiesFactory"></add>
         </appSettings>
</configuration>

然后，在代码中读取这个配置字段，根据配置字段的值来做实现。首先实现一个构建方法，然后再在客户程序中调用。

public static FacilitiesFactory GetInstance()
{
    string factoryName = ConfigurationSettings.AppSettings["factoryName"];
    FacilitiesFactory f;
    switch (factoryName)
    {
        case "ModernFacilitiesFactory":
            f = new ModernFacilitiesFactory();
            break;
        case "ClassicFacilitiesFactory":
            f = new ClassicFacilitiesFactory();
            break;
        default:
            f = null;
            break;
    }

    return f;
}
//客户程序
public static void Main()
{
    GameManager g = new GameManager(GetInstance());
    g.BuildGameFacilities();
    g.Run();
}

第二种改造

其实还有一种需求就是扩展新的系列对象，如果还是不需要对客户程序进行维护，而仅是添加了新的系列对象的类，那将是很舒服的一件事。这样我们就可以通过添加DLL并配合配置文件的使用，就能在不修改源程序代码的情况下，扩展出我们需要的新的系列对象

public staticFacilitiesFactory GetInstance()
{
    string factoryName = ConfigurationSettings.AppSettings["factoryName"];
    FacilitiesFactory f;
    if (factoryName != "")
        f = (FacilitiesFactory)Assembly.Load(factoryName).CreateInstance(factoryName);
    else
        f = null;
    return f;
}

这样，我们在扩展时仅需将扩展的DLL放在相应的路径下并配合配置文件即实现了我们的扩展。

六、抽象工厂的实现要点

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

抽象工厂模式的优点：

【抽象工厂】模式将系列产品的创建工作延迟到具体工厂的子类中，我们声明工厂类变量的时候是使用的抽象类型，同理，我们使用产品类型也是抽象类型，这样做就尽可能的可以减少客户端代码与具体产品类之间的依赖，从而降低了系统的耦合度。耦合度降低了，对于后期的维护和扩展就更有利，这也就是【抽象工厂】模式的优点所在。可能有人会说在Main方法里面（这里的代码就是客户端的使用方）还是会使用具体的工厂类，对的。这个其实我们通过Net的配置，把这部分移出去，最后把依赖关系放到配置文件中。如果有新的需求我们只需要修改配置文件，根本就不需要修改代码了，让客户代码更稳定。依赖关系肯定会存在，我们要做的就是降低依赖，想完全去除很难，也不现实。

抽象工厂模式的缺点：

有优点肯定就有缺点，因为每种模式都有他的使用范围，或者说要解决的问题，不能解决的问题就是缺点了，其实也不能叫缺点了。【抽象工厂】模式很难支持增加新产品的变化，这是因为抽象工厂接口中已经确定了可以被创建的产品集合，如果需要添加新产品，此时就必须去修改抽象工厂的接口，这样就涉及到抽象工厂类的以及所有子类的改变，这样也就违背了“开发——封闭”原则。

抽象工厂模式的使用场景：

如果系统需要多套的代码解决方案，并且每套的代码方案中又有很多相互关联的产品类型，并且在系统中我们可以相互替换的使用一套产品的时候可以使用该模式，客户端不需要依赖具体实现。

七、.NET中抽象工厂模式实现

微软的类库发展了这么多年，设计模式在里面有大量的应用，【抽象工厂】模式在.NET类库中也存在着大量的使用，比如和操作数据库有关的类型，这个类就是System.Data.Common.DbProviderFactory，这个类位于System.Data.dll程序集中。该类扮演抽象工厂模式中抽象工厂的角色，DbProviderFactory就是【抽象工厂】模式UML里面AbstractFactory类型。其他具体的工厂类型继承DbProviderFactory类型。

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/springsnow/p/11302780.html