C++设计模式第二讲

《C++设计模式教程》第二讲：工厂模式主讲人：步磊峰UIPower3D界面引擎负责人第一节：简单工厂模式介绍21、从设计模式的类型上来说，简单工厂模式是属于创立型模式，又叫做静态工厂方法〔StaticFactoryMethod〕模式。

2、但它并不属于23种GOF设计模式之一，之所以在此论述，是为了引出GOF工厂方法模式。3、简单工厂模式是由一个工厂对象(Factory)决定创立出哪一种产品类(Product)的实例。4、简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。

第二节：简单工厂模式一个简单例子3

第二节：简单工厂模式一个简单例子4第二节：简单工厂模式一个简单例子5第三节：简单工厂描述61、意图：定义一个创立对象的接口，根据所提供的参数决定创立出哪个一个实体类的一个实例。简单工厂模式封装了对象的创立过程。2、别名：静态工厂3、结构：

第三节：简单工厂描述74、动机：为了提高内聚和松耦合，我们经常会抽象出一些类的公共接口，以形成抽象基类或接口，这样我们可以声明一个指向基类的指针来指向实际的子类实现，从而到达多态的目的。

但这样容易出现一个问题:大量的子类继承自抽象基类，我们不得不在每次都要使用到子类的地方编写诸如"newXXX();"的代码，从而带来两个问题：1)客户程序员必须知道子类的名字，当系统复杂时，为了处理可能的名字冲突，可能使用不具有很到的可读性和可记性的名字。2)程序的扩展和可维护性越来越困难。而这就是简单工厂要解决的。通过定义创立对象的接口，封装对象的创立，与客户端程序员无关，增强程序的可扩展性及可维护性。

第三节：简单工厂描述85、参与者：1)AbstractProduct定义简单工厂方法所创立的产品的接口。2)ConcreteProduct实现AbstractProduct的接口。3)Factor定义一个简单工厂方法，内部创立实际的ConcreteProduct，并返回基类地址。6、适用：主要运用于工具包或框架的开发。

第三节：简单工厂的优缺点9优点：工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创立哪个具体类的对象.通过使用工厂类,外界可以从直接创立具体产品对象的为难局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创立及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。缺点：由于工厂类集中了所有实例的创立逻辑，违反了高内聚责任分配原那么，将全部创立逻辑集中到了一个工厂类中；它所能创立的类只能是事先考虑到的，如果需要添加新的类，那么就需要改变工厂类了。当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创立不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难防止模块功能的蔓延，对系统的维护和扩展非常不利；而这些缺点在工厂方法模式中得到了一定的克服。

第四节：工厂方法模式介绍101、工厂方法(FactoryMethod)模式的意义是定义一个创立产品对象的工厂接口，将实际创立工作推迟到子类当中。

2、核心工厂类不再负责产品的创立，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口。3、这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。。4、工厂方法模式是简单工厂模式的衍生，解决了许多简单工厂模式的问题。1)首先完全实现‘开－闭原那么’，实现了可扩展。2)其次更复杂的层次结构，可以应用于产品结果复杂的场合。

第五节：改写简单工厂模式例子11

第六节：工厂方法描述121、意图：定义一个创立对象的接口，让子类决定实例化哪一个类。工厂方法模式使一个类的实例化延迟到其子类。象的创立过程。2、别名：虚构造器(VirtualConstructor)3、结构：

第六节：工厂方法描述134、参与者：1)AbstractProduct定义简单工厂方法所创立的产品的接口。2)ConcreteProduct实现AbstractProduct的接口。3)AbstractFactory声明了一个工厂方法，该方法返回一个AbstractProduct对象。4)ConcreteFactory实现了基类的方法，内部创立对象的ConcreteProduct，返回的是基类AbstractProduct对象。

第六节：工厂方法描述145、适用：主要应用与两种情况：第一种情况是对于某个产品，调用者清楚地知道应该使用哪个具体工厂效劳，实例化该具体工厂，生产出具体的产品来。第二种情况，只是需要一种产品，而不想知道也不需要知道究竟是哪个工厂为生产的，即最终选用哪个具体工厂的决定权在生产者一方，它们根据当前系统的情况来实例化一个具体的工厂返回给使用者，而这个决策过程这对于使用者来说是透明的。

第七节：返璞归真15

使用工厂方法虽然进行了解耦，使程序更加灵活，但是也带来了类膨胀的后果。如果我们使用工厂方法仅仅是为了解决前面提到的简单工厂的缺陷，那么我们会发现有点小题大做了。C++的模板机制允许我们使用简单工厂的方式来解决非模板简单工厂的缺陷。

第七节：返璞归真16

代码演示:

第七节：返璞归真17

第八节：工厂方法进一步应用18现在假设我们要生产一辆组装车，该车由引擎，底盘以及轮子组合而成，在不修改我们前面的代码的根底上进行扩展。代码如下:

第八节：工厂方法进一步应用19现在假设我们要生产一辆组装车，该车由引擎，底盘以及轮子组合而成，在不修改我们前面的代码的根底上进行扩展。代码如下:

第八节：工厂方法进一步应用20现在假设我们要生产一辆组装车，该车由引擎，底盘以及轮子组合而成，在不修改我们前面的代码的根底上进行扩展。代码如下:

第八节：工厂方法进一步应用21现在假设我们要生产一辆组装车，该车由引擎，底盘以及轮子组合而成，在不修改我们前面的代码的根底上进行扩展。测试结果：

由此可见，工厂方法可以用于更加复杂的对象创立过程。耦合性非常的低，易于扩展。工厂方法符合了面向对象中的开放-封闭原那么(OCP)。关于开发封闭原那么，其核心的思想是：

软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。第九节：抽象工厂模式的引入22我们继续以汽车生产商生产汽车的例子来进一步描述抽象工厂模式。前面的例子各个汽车厂商仅仅生产一种产品(CarBase)。事实上我们发现各个汽车厂商生产的产品线非常庞大，单单轿车(Car)可分为商务轿车和跑车等等。而前面论述的简单工厂或工厂方法仅仅只能生产一种产品，如果要生产一系列产品，如何办呢?这时候我们就需要引入抽象工厂设计模式！

第十节：抽象工厂模式介绍231)当每个抽象产品都有多于一个的具体子类的时候，工厂角色怎么知道实例化哪一个子类呢？比方每个抽象产品角色都有两个具体产品！2)抽象工厂模式提供两个具体工厂角色，分别对应于这两个具体产品角色，每一个具体工厂角色只负责某一个产品角色的实例化。3)每一个具体工厂类只负责创立抽象产品的某一个具体子类的实例。4)每一个模式都是针对一定问题的解决方案，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式针对的是多个产品等级结构(产品族)。第十一节：抽象工厂例子24

第十一节：抽象工厂例子25

第十一节：抽象工厂例子26

第十一节：抽象工厂例子27

第十二节：抽象工厂模式描述281、意图：提供一个创立一系列相关或相互依赖对象的接口，而书序指定他们具体的类。2、别名：Kit3、结构：

第十二节：抽象工厂模式描述294、参与者：1)AbstractFactory声明了一系列创立同一层次的不同产品族的抽象方法，这些方法返回所对应的AbstractProduct对象。2)ConcreteFactory实现了创立具体产品对象的操作。2)AbstractProduct为某一类产品声明了一个接口。4)ConcreteProduct实现了AbstractProduct接口。

第十二节：抽象工厂模式描述305、适用：1)系统不依赖于产品类实例如何被创立，组合和表达的细节。2)系统的产品有多于一个的产品族，而系统只消费其中某一族的产品(抽象工厂模式的原始用意Unix&Windows〕Button--->UnixButton/WinButtonText----->UnixText/WinTextUnix产品族和Windows产品族，不会同时使用。GUIFactory--->UnixGUIFactory/WinGUIFactory3)同属于同一个产品族是在一起使用的。这一约束必须在系统的设计中表达出来。4)系统提供一个产品类的库，所有产品以同样的接口出现，从而使客户端不依赖于实现。

第十二节：抽象工厂模式描述315、优缺点：1)别离了具体的类。(别离了工厂，别离了产品)2)易于交换产品族(或称为产品系列)。我们可以进行产品配置，例如在win32中使用winGUI控件。在unix下使用UnixGUI控件。3)有利于产品的一致性。(winGUI和UnixGUI控件使用一致的接口，只需更改配置，不需要重新编译修改)4)难以支持新的产品族(或称为产品系列)。这是因为AbstractFactory接口确定了可以被创立的产品集合。支持新种类的产品就需要扩展该工厂接口，这将涉及AbstractFactory类及其所有子类的改变。(只是繁而已，但是能实现)

第十三节：抽象工厂在GUI系统中的经典应用32

第十四节：对抽象工厂模式的扩展33在前面描述抽象工厂的优缺点时，提到了抽象工厂模式的一个缺点：难以支持新的产品族(或称为产品系列)。这是因为AbstractFactory接口确定了可以被创立的产品集合。支持新种类的产品就需要扩展该工厂接口，这将涉及AbstractFactory类及其所有子类的改变。(只是繁而已，但是能实现)

还是以工厂生产汽车为例子，假设我们现在要增加一种产品族:卡车。奔驰和宝马公司都要生产卡车。那么我们将如何做呢?

第十四节：对抽象工厂模式的扩展341、增加两个接口类

第十四节：对抽象工厂模式的扩展352、实现奔驰和宝马的卡车产品

第十四节：对抽象工厂模式的扩展363、实现扩展的奔驰和宝马的工厂类

第十四节：对抽象工厂模式的扩展374、测试代码

由此可见，虽然对抽象工厂扩展比较麻烦，但是并非不可能。抽象工厂也符合面向对象的开放-封闭原那么(OCP)。同时我们在抽象工厂的过程中又使用了面向对象的另外一个原那么：优先使用组合而不是继承原那么(CARP,Composite/AggregateReusePrinciple)。我们还可以使用单例模式对抽象工厂进一步进行封装。第十五节：面向对象的七大原那么381)单一职责原那么(SRP,SingleResponsibilityPrinciple)类的职责要单一，对外只提供一种功能，而引起类变化的原因都应该只有一个。2)开放封闭原那么(OCP,OpenForExtension,ClosedForModificationPrinciple)类的改动是通过增加代码进行的，而不是修改源代码。3)依赖倒置原那么(DIP,DependenceInversionPrinciple)依赖于抽象(接口),不要依赖具体的实现(类)，也就是针对接口编程。4)接口隔离原那么(ISP,InterfaceSegegationPrinciple)不应该强迫客户的程序依赖他们不需要的接口方法。一个接口应该只提供一种对外功能，不应该把所有操作都封装到一个接口中去。

最终目的：高内聚，低耦合第十五节：面向对象的七大原那么39

5)里氏替换原那么(LSP,LiskovSubstitutionPrinciple)