设计模式（三）创建型模式

Posted 2023-04-28

参考技术A 根据菜鸟教程的目录，我们首先来看看创建型模式。 创建型模式研究：

下面分别对创建型模式下的各种具体模式进行讲解。

先看例子： 工厂模式。

某功能的使用者只和接口打交道，不关心如何实现。这种情况下，肯定有一个接口类，使用者使用接口；功能提供者继承并实现接口。这利用了C++的多态特性。

既然使用者只关心接口，那么没有必要把子类直接给使用者，没有必要让使用者在代码中直接new子类。如果这样做，会把不必要的信息暴露给使用者，增加了信息的耦合。试想，如果使用者在很多地方都new了子类，那么如果这些地方需要修改的话，怎么改？只能一个一个地方改，改完还需要编译，维护极其困难。

工厂模式是指，针对某一功能接口，我们要新建一个工厂类，此工厂类将接口子类名称、接口子类的创建过程封装起来，只返回一个接口指针给接口的使用者。接口的实现类对使用者完全透明，高度解耦。这样可以方便地切换接口的具体实现，而不影响上层功能使用者。拿 汽车 打比方，不管工厂生产 汽车 的流程是什么，只要是 汽车 ，它的驾驶方法（人机接口）都类似。

显而易见，工厂模式在使用者和实现者之间增加了一个封装层，这正印证了计算机行业中一句名言：

典型的例子是：Qt中的数据库模块就利用了工厂模式，封装了数据库的底层实现。在保持数据库用户接口不变的情况下，通过更换数据库驱动，可以实现数据库类型无缝切换。

在需求趋于稳定时使用，需求不稳定时，不要过度设计，否则设计很容易被推翻，白费力气。

从设计模式的本质来看，工厂模式：

先看例子： 抽象工厂模式。

由前面工厂模式可知，所有的“工厂”有一个共同点：每个工厂都会提供创建对象的函数。 既然所有工厂都实现了同一类功能，那么我们可以为工厂抽象出一个公共接口（虚基类），此接口定义了创建工厂子类的功能。 这种场景是否似曾相识？是的，工厂和工厂的功能接口构成了使用工厂模式的场景。即工厂本身也适用于工厂模式。 使用工厂模式来设计工厂，必然要写一个生产工厂的工厂。 生产工厂的工厂，返回值是工厂的抽象接口类，所以这种设计模式叫“抽象工厂模式”。其实，笔者觉得把这种设计模式叫做“工厂工厂模式”更容易理解。

如果只有一个工厂就不要使用抽象工厂模式了，只有在工厂很多时，才使用抽象工厂模式。

需求不稳定时，不要过度设计，一切都可能被推翻。 对于小的项目，不需要过度追求使用设计模式，架构的代码最好只占整个项目代码的一小部分，否则就是主次颠倒，给自己找麻烦。 对于大的项目，在需求较稳定的情况下，为了提高可维护性、扩展性，可以考虑使用设计模式。 另外，抽象工厂模式有一定的理解难度，要考虑你设计的代码，其他人是否能够读懂，简单易懂也是需要考虑的方面。

所以，从设计模式的本质来看，

先看例子： 单例模式。

上面的例子都是允许一个类被创建多次的。如果我们想要限制一个类只被创建一次，即只有一个全局可访问的实例（和C语言中的全局变量一样），例如应用程序对象，每个应用程序都应该只有一个应用程序对象。此时应该怎么编写代码呢？

答案还是封装。把不想暴露出来的信息藏起来，把必须暴露的信息暴露出来。单例模式把类的构造函数设置成private私有访问权限，限制外部无法通过new来创建实例。只能通过特定的接口来获取实例指针。需要提及的是，封装时需要考虑多线程安全的问题。

当一个类需要有多个实例存在时，不使用单例模式。

从设计模式的本质上看，

具体的例子和写法，可以参考菜鸟教程中的 建造者模式。

建造者模式的典型使用场景是快餐店的套餐搭配模型。 套餐由若干个单个餐品组合而成。单个餐品又由不同的原材料构成。这种层层组合的树形对象关系的应用场景下，为了创建顶层的对象，需要先一层层的创建底层的对象，逐步向上，直到构造出根对象。 这种场景下，使用继承可以将同类的对象关联起来，使用组合可以将不同类型的对象组合起来。组合就是把不同对象放在一块内存中保存，作为一个整体使用。

完全使用继承来解决此类问题是非常不提倡的。设计模式理论中有一个原则是：“少用继承，多用组合”。因为继承是一种强耦合，组合是一种松散的耦合。耦合不利于适应需求变化，是项目中的一颗定时炸弹。

从设计模式的本质上看，

菜鸟教程中没有提及的一种设计模式是组合模式。具体内容可以参考： 第四节：组合模式和建筑者模式详解。

这里简单说明一下，组合模式和建造者模式比较像，也是遵循树形对象关系结构。和建造者模式相比，不同之处在于，子对象和父对象具有相同的类型。所以可以说，组合模式是简单的建造者模式。

具体的使用场合和实例，见原型模式。

原型模式，在实际使用时可能用得不多。用一句话描述其特点：

这种克隆是一种内存中的复制行为，速度快，能充分利用已有对象的缓存数据，性能高。克隆出来的对象具有和原对象相同的属性和行为，可以用来帮助原对象处理一些事务。用一句动漫中的词汇来描述，“影分身”再合适不过了。

从设计模式的本质看，

下一篇，我们将介绍结构型模式。

C#设计模式之三抽象工厂模式（AbstractFactory）创建型

一、引言

     写了3篇有关设计模式的文章了，大家有了些反馈，说能从中学到一些东西，我感到很欣慰，那就继续努力。今天我要写第四个模式了，该模式叫抽象工厂。上一篇文章我们讲了【工厂方法】模式，它是为了解决【简单工厂】模式所面对的问题，它的问题就是：如果我们增加新的产品，工厂类的方法就要修改本身的代码，增加产品越多，其逻辑越复杂，同时这样的修改也是不符合【开放关闭原则OCP】，对修改代码关闭，对增加代码开放。为了解决【简单工厂】的问题，我们引出了【工厂方法】模式，通过子类化工厂类，解决了工厂类责任的划分，产品和相应的工厂一一对应，符合了OCP。如果我们要设计一套房子，当然我们知道房子是由房顶、地板、窗户、房门组成的，别的组件暂时省略，先设计一套古典风格的房子，再创建一套现代风格的房子，再创建一套欧式风格的房子，这么多套房子，我们该怎么办呢？今天我们要讲的【抽象工厂】模式可以很好的解决多套变化的问题。

二、抽象工厂详细介绍

  2.1、动机(Motivate)：

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

  2.2、意图(Intent):

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

  2.3、结构图（Structure）

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

2.4、模式的组成

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

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

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

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

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

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

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

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

  让我们看看该模式如何应对需求的变化，假设我的表弟一看我们的房子很好，他也想要一套古典风格的房子（哈哈，这个家伙事挺多的，有好事总是落不下他）。

 此时，只需要添加五个类：一个是古典风格工厂类，负责创建古典风格的房子，另外几个类是具有古典风格的房顶、地板、窗户和房门的具体产品。从上面代码看出，抽象工厂对于系列产品的变化支持 “开放——封闭”原则（指的是要求系统对扩展开放，对修改封闭），扩展起来非常简便，但是，抽象工厂对于增加新产品这种情况就不支持”开放——封闭 “原则，因为要修改创建系列产品的抽象基类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对象（这个是抽象产品类,如绝味例子中的YaBo类）、DbCommand类、DbDataAdapter类，针对不同的具体工厂都需要实现该抽象类中方法，

DbProviderFactory类是一个抽象工厂类，该类提供了创建数据库连接时所需要的对象集合的接口，实际创建的工作在其子类工厂中进行，微软使用的是SQL Server数据库，因此提供了连接SQL Server数据的具体工厂实现，具体代码可以用反编译工具查看，具体代码如下：

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

dbcFactory也是具体工厂类

当然，我们也有OleDbFactory 类型，都是负责具体的数据库操作。DbProviderFactory就是【抽象工厂】模式UML里面AbstractFactory类型。其他具体的工厂类型继承DbProviderFactory类型，这个结构很简单，我就不画图了。

五、总结

   终于写完了，写了3个小时，学习设计模式不能死学，要把握核心点和使用场景。关键点第一是，面向对象设计模式的基本原则，有了原则，考虑问题就不会跑偏，然后再仔细把握每种模式的使用场景和要解决的问题，多写写代码，多看看Net的类库，它是最好的教材。

天下国家,可均也；爵禄,可辞也；白刃,可蹈也；中庸不可能也