本笔记摘抄自：https://www.cnblogs.com/PatrickLiu/p/7596897.html，记录一下学习过程以备后续查用。

    一、引言

    接上一篇C#设计模式学习笔记：简单工厂模式(工厂方法模式前奏篇)，通过简单工厂模式的了解，它的缺点就是随着需求的变化我们要不停地修改工厂里

    上一篇文章我们讲了工厂方法模式，它是为了解决简单工厂模式所面对的问题：如果我们增加新的产品，工厂类的方法就要修改本身的代码，增加产品越

多，其逻辑越复杂，同时这样的修改也不符合开放闭合原则OCP--对增加代码开放，对修改代码关闭。为了解决简单工厂的问题，我们引出了工厂方法模式，

通过子类化工厂类，解决了工厂类责任的划分，使得产品和相应的工厂一一对应，符合了OCP。

    如果我们要设计一套房子，当然我们知道房子是由房顶、地板、窗户、房门等组成的，先设计一套古典风格的房子，再创建一套现代风格的房子，再创建

一套欧式风格的房子，这么多套房子，我们该怎么办呢？今天我们要讲的抽象工厂模式可以很好地解决多套变化的问题。

    二、抽象工厂模式介绍

    抽象工厂模式：英文名称--Abstract Factory Pattern；分类--创建型。

    2.1、动机(Motivate)

    在软件系统中，经常面临着"一系列相互依赖的对象"的创建工作，同时，由于需求的变化，往往存在更多系列对象的创建工作。如何应对这种变化？如何

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

    2.2、意图(Intent)

    提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。——《设计模式》GoF

    2.3、结构图（Structure）

    该图是抽象工厂的UML图，结合抽象工厂的意图、动机和图示来理解该模式，今天我们就以建设房子为例来说明抽象工厂的实现机理。

    2.4、模式的组成

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

    1）抽象产品类角色（AbstractProduct）：为抽象工厂中相互依赖的每种产品定义抽象接口对象，也可以这样说，有几种产品，就要声明几个抽象角色，

每一个抽象产品角色和一种具体的产品相匹配。

    2）具体产品类（ConcreteProduct）：具体产品类实现了抽象产品类，是针对某个具体产品的实现的类型。

    3）抽象工厂类角色（AbstractFactory）：定义了创建一组相互依赖的产品对象的接口操作，每种操作和每种产品一一对应。

    4）具体工厂类角色（ConcreteFactory）：实现抽象类里所有抽象接口操作，可以创建某系列具体的产品，这些具体的产品是“抽象产品类角色”的子类。

    2.5、抽象工厂模式的具体实现

    随着我们年龄的增长，我们也到了结婚的年龄，结婚首要的问题就是房子的问题。假设我有一个很有钱的爸爸(呃，发梦中……)，我的哥哥们希望能有

一套欧式风格的房子，再加上田园风光，悠闲自在。而我就不一样了，我希望有一套现代样式的房子。由于房子由房顶、地板、窗户和房门组成（其他组

件暂时省略），每套房子的房顶、地板、窗户和房门都是一个体系的。

    下面让我们看看如何使用抽象工厂模式来实现不同房屋的建造：

 View Code

    运行结果如下：

    2.6、 抽象工厂模式应对需求变更

    假设我的姐姐一看我们的房子很好，她希望有一套古典风格的房子，怎么处理呢？

 View Code

    运行结果如下：

    从上面代码可以看出，需要添加5个类：4个类分别创建古典风格的房顶、地板、窗户和房门的具体产品，另外一个是古典风格房子的工厂类，负责创建

古典风格的房子。

    从上面代码可以看出，抽象工厂对于系列产品的变化支持开闭原则（对扩展开放，对修改封闭），扩展起来非常简便。但是，抽象工厂对于增加新产品

这种情况就不支持开闭原则，因为要修改创建系列产品的抽象基类AbstractFactory，增加相应产品的创建方法，这也是抽象工厂的缺点所在。

    三、抽象工厂模式的实现要点

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

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

    3）AbstractFactory模式主要在于应对“新系列”的需求变动，其缺点在于难以应对“新对象”的需求变动。

    4）AbstractFactory模式经常和FactoryMethod模式共同组合来应对“对象创建”的需求变化。

    3.1、抽象工厂模式的优点

    抽象工厂模式将系列产品的创建工作延迟到具体工厂的子类中，我们声明工厂类变量的时候使用的是抽象类型，同理，我们使用产品类型也是抽象类型，

这样做可以尽可能地减少客户端代码与具体产品类之间的依赖，从而降低了系统的耦合度。耦合度降低了，对于后期的维护和扩展就更有利，这就是抽象

工厂模式的优点所在。

    可能有人会说在Main方法里面（客户端）还是会使用具体的工厂类，对的。这个其实我们可以通过.Net配置文件把这部分移出去，把依赖关系放到配置文

件中。如果有新的需求我们只需要修改配置文件，根本就不需要修改代码了，让客户代码更稳定。依赖关系肯定会存在，我们要做的就是降低依赖，想完全

去除很难，也不现实。

    3.2、抽象工厂模式的缺点

    有优点肯定就有缺点，因为每种模式都有它的使用范围，或者说不能解决的问题就是缺点。抽象工厂模式很难支持增加新产品的变化，这是因为抽象工厂

接口中已经确定了可以被创建的产品集合，如果需要添加新产品，此时就必须去修改抽象工厂的接口，这样就涉及到抽象工厂类以及所有子类的改变，这样

也就违背了开闭原则。

    3.3、抽象工厂模式的使用场景

    如果系统需要多套的代码解决方案，并且每套的代码方案中又有很多相互关联的产品类型，并且在系统中可以相互替换地使用一套产品的时候就可以使用

该模式，客户端不需要依赖具体实现。

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

    微软的类库发展了这么多年，设计模式在里面有大量的应用。抽象工厂模式在.NET类库中也存在着大量的使用，比如和操作数据库有关的类型，这个类是

System.Data.Common.DbProviderFactory，此类位于System.Data.dll程序集中。该类扮演抽象工厂模式中抽象工厂的角色，我们可以用ILSpy反编译工具查

看该类的实现：

    /// 扮演抽象工厂的角色
    /// 创建连接数据库时所需要的对象集合
    /// 这个对象集合包括有DbConnection对象（抽象产品类）、DbCommand类、DbDataAdapter类，针对不同的具体工厂都需要实现该抽象类中的方法。

 View Code

    DbProviderFactory类是一个抽象工厂类，该类提供了创建数据库连接时所需要的对象集合的接口，实际创建工作在其子类工厂中进行。微软使用的是

SQL Server数据库，因此提供了连接SQL Server数据的具体工厂实现，具体代码可以用反编译工具查看。

    SqlClientFactory扮演着具体工厂的角色，用来创建连接SQL Server数据所需要的对象：

 View Code

    OdbcFactory也是具体工厂类：

 View Code

    当然，我们也有OleDbFactory类型，都是负责具体的数据库操作。DbProviderFactory就是抽象工厂模式UML里面AbstractFactory类型，其它具体的工厂类

型继承于DbProviderFactory类型。

    五、总结

    学习设计模式不能死学，要把握核心点和使用场景，关键点是面向对象设计模式的基本原则。有了原则，考虑问题就不会跑偏，然后再仔细把握每种模式的

使用场景和要解决的问题，多写写代码，多看看Net的类库，它是最好的教材。