常用设计模式
常见的二十三种设计模式
常见的⼆⼗三种设计模式按照⽬的来分，设计模式可以分为创建型模式、结构型模式和⾏为型模式。
创建型模式⽤来处理对象的创建过程；结构型模式⽤来处理类或者对象的组合；⾏为型模式⽤来对类或对象怎样交互和怎样分配职责进⾏描述。
创建型模式⽤来处理对象的创建过程，共以下五种：单例模式（Singleton Pattern）能避免同⼀对象被反复实例化。
⽐如说，访问数据库的连接对象就⽐普通对象实例化的时间要长;WCF中，维护服务器端远程对象的创建等，这类情况，很有必要⽤单例模式进⾏处理对象的实例化。
简单⼯⼚模式通过在⼯⼚类中进⾏判断，然后创建需要的功能类。
优点：不必使⽤具体的功能类去创建该类的实例。
缺点：新增⼀个功能类就需要在⼯⼚类中增加⼀个判断。
⼯⼚⽅法模式（Factory Method Pattern）把简单⼯⼚模式中的⼯⼚类，做了进⼀步的抽象为接⼝或抽象类，给各个功能创建⼀个对应的⼯⼚类，然后在这个⼯⼚类⾥⾯去创建对应的实例。
缺点：当新增⼀个功能类，就需要创建对于的⼯⼚类，相⽐简单⼯⼚模式，免去了判断创建那个具体实例，但会创建过多的类，还不如策略模式。
抽象⼯⼚模式（Abstract Factory Pattern）使⽤该功能类的功能类，利⽤抽象⼯⼚去创建该功能类的实例。
这样的好处在于尽可能的避免去创建功能的实例。
更⽜逼的做法就是使⽤反射去创建这个功能类的实例，在调⽤端就⼀点都不需要知道要去实例化那个具体的功能类。
这当然不是抽象⼯⼚模式独有的。
建造者模式（Builder Pattern）每个对象都具备⾃⼰的功能，但是，它们的创建⽅式却是⼀样的。
这个时候就需要中间这个建造者类来负责功能对象实例的创建。
在调⽤端只需调⽤特定的⽅法即可。
这个和策略模式有点类似。
原型模式（Prototype Pattern）创建好了⼀个实例，然后⽤这个实例，通过克隆⽅式创建另⼀个同类型的实例，⽽不必关⼼这个新实例是如何创建的。
原型模式使⽤时需要注意浅拷贝与深拷贝的问题。
23种设计模式范文
23种设计模式范文设计模式是软件开发中常用的解决方案模式，它们代表了在面对特定问题时的最佳实践和经验总结。
设计模式可以帮助我们更好地组织和设计代码，提高代码的可读性、可维护性和可扩展性。
在本文中，我们将介绍23种常用的设计模式，并分别讨论它们的实现原理和在实际开发中的应用场景。
1. 单例模式（Singleton Pattern）单例模式是最简单的设计模式之一，它确保一个类只有一个实例，并提供一个全局访问点。
在实现上，可以通过将构造函数私有化，然后提供一个静态方法返回实例来实现单例。
应用场景：在需要实现全局唯一访问点的场景下，比如线程池、配置管理器等。
2. 工厂模式（Factory Pattern）工厂模式是用来创建对象的一种模式，它将对象的创建和实现分离，使得代码更易于维护和扩展。
工厂模式有简单工厂模式、工厂方法模式和抽象工厂模式等几种不同的变体。
应用场景：在需要根据不同条件创建不同对象的场景下，比如数据库连接、日志记录等。
3. 抽象工厂模式（Abstract Factory Pattern）抽象工厂模式是工厂模式的一种扩展，它提供一个创建一系列相关或相互依赖对象的接口，而无需指定实际的类。
抽象工厂模式将一组工厂类封装起来，使其可以交换或者替换。
应用场景：在需要创建一组相关对象（如界面主题、操作系统等）并且需要保持一致性的场景下。
4. 建造者模式（Builder Pattern）建造者模式是用来生成复杂对象的一种模式，它将对象的构建与其表现分离，采用逐步构建的方式生成对象，可以让客户端不需要知道具体的构建细节。
应用场景：在构造过程比较复杂，需要多个组件协同工作的场景下，比如构建复杂的UI界面。
5. 原型模式（Prototype Pattern）原型模式是用来克隆对象的一种模式，它通过复制已有对象的原型来创建新的对象，避免了通过构造函数创建对象和初始化成员变量的重复过程。
应用场景：在需要创建大量相似对象或者初始化成本较高的对象时，可以使用原型模式。
23种设计模式 详解
23种设计模式详解设计模式是指面向对象编程中，经过多次验证、被广泛接受的代码实现方法。
这些设计模式可以帮助开发者更快地解决问题，提高代码的可读性、可维护性、可扩展性。
目前，常用的设计模式有23种。
下面，我们来详细介绍一下这23种设计模式。
1. 单例模式(Singleton)单例模式是一种只允许生成一个实例的模式。
在实例化对象时，单例模式的生成过程比较特殊，需要先判断该类是否已经实例化过，如果已经实例化，则直接返回已有的实例对象，否则再进行实例化。
2. 工厂模式(Factory)工厂模式是一种生产对象实例的设计模式。
它将对象实例的生成过程封装在一个工厂类中，客户端需要对象时，只需要调用工厂类中对应的方法即可。
3. 抽象工厂模式(Abstract Factory)抽象工厂模式是一种扩展了工厂模式的模式。
它可以生成一系列相关或相互依赖的对象实例。
具体实现时，通常需要定义一个抽象工厂类和一些具体工厂类，来生产各种相关的对象实例。
4. 建造者模式(Builder)建造者模式是一种用于构建复杂对象的模式。
它将一个复杂对象的构建过程分解成多个简单的步骤，然后通过一个指挥者来管理这些步骤的执行，最终构建出一个复杂的对象。
5. 原型模式(Prototype)原型模式是一种通过复制已有对象来创建新对象的模式。
一般来说，系统中的对象包含大量相同或相似的部分，通过复制对象可以帮助我们节省生成对象的时间和资源。
6. 适配器模式(Adapter)适配器模式是一种将不兼容接口转换为兼容接口的模式。
具体实现时，需要定义一个适配器类，该类实现了客户端所期望的接口，而且还包装了原有不兼容的接口，使其能够兼容客户端期望的接口。
7. 桥接模式(Bridge)桥接模式是一种将抽象部分与其实现部分分离开来的模式。
具体实现时，需要定义抽象部分和实现部分的接口，然后定义一个桥接类，将抽象部分和实现部分联系起来。
8. 组合模式(Composite)组合模式是一种将具有相同属性和方法的对象组合成树形结构的模式。
常见的设计模式和最佳实践
常见的设计模式和最佳实践设计模式是软件开发中常用的一种解决问题的方法论，它简化了代码的复杂性，提高了代码的可读性和可维护性。
设计模式可以让你有效地组织代码，让你的代码架构更加清晰并易于维护。
在本文中，我们将会介绍常见的设计模式和最佳实践。
一、单例模式单例模式是一种常用的设计模式，用于创建一个全局唯一的对象。
在单例模式中，一个类只能被实例化一次，而且这个实例化过程必须由该类自行完成。
这种方式可以优化系统资源的利用，防止重复创建对象，并且可以更好地控制对象的访问权限。
在使用单例模式时，需要注意以下几点：1.确保线程安全：在多线程环境下，需要保证单例的实例只被创建一次，避免多个线程同时创建实例导致的问题。
2.避免反序列化问题：在反序列化时，可能会创建多个对象，需要使用枚举或序列化方法等方式避免这个问题。
3.不要使用全局变量：单例模式并不等于全局变量。
全局变量可能会带来很多问题，需要避免使用。
二、工厂模式工厂模式是一种用于创建对象的设计模式。
它定义了一个工厂接口和多个具体的工厂类，每个工厂类都负责创建一种特定类型的对象。
当需要创建对象时，可以根据需要选择使用哪个具体的工厂类。
这种方式可以将对象的创建过程与客户代码分离，提高代码的可维护性和可重用性。
在使用工厂模式时，需要注意以下几点：1.确保工厂类的可扩展性：工厂模式允许你随时添加新的工厂类来创建新的对象类型。
需要确保工厂类的可扩展性和灵活性。
2.避免创建过多的工厂类：虽然工厂模式可以增加灵活性和可重用性，但是过多的工厂类会增加系统的复杂性，需要权衡利弊。
3.注意工厂类的职责：每个具体的工厂类都应该负责创建一种特定类型的对象，需要避免工厂类职责模糊不清的情况出现。
三、观察者模式观察者模式是一种常用的设计模式，用于对象之间的消息传递和事件处理。
在观察者模式中，一个对象（被观察者）会通知其它所有对象（观察者）自己的状态发生了改变。
这种方式可以实现对象之间的松耦合，提高系统的灵活性和可维护性。
23种设计模式记忆口诀
23种设计模式记忆口诀根据内容要求，对23种设计模式进行简要说明，并整理成口诀。
设计模式是软件开发中常用的一种解决方案，它提供了面向对象设计和编程中常见问题的解决思路和方法。
根据GoF（Gang of Four）的分类，设计模式可以分为创建型、结构型和行为型三种类型，共23种设计模式。
1. 创建型模式（Creational Patterns）：- 工厂方法模式（Factory Method Pattern）：定义一个用于创建对象的接口，但由子类决定实例化的类。
- 抽象工厂模式（Abstract Factory Pattern）：提供一个创建一系列相关对象或依赖对象的接口，而无须指定它们的具体类。
- 单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供一个全局访问点。
- 原型模式（Prototype Pattern）：用于创建重复性对象的一个原型。
- 建造者模式（Builder Pattern）：将一个复杂对象的构建和表示分离，使得同样的构建过程可以创建不同的表示。
2. 结构型模式（Structural Patterns）：- 适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。
- 桥接模式（Bridge Pattern）：将抽象部分和它真正的实现分离，使它们独立的变化。
- 装饰器模式（Decorator Pattern）：动态地将责任附加到对象上，扩展功能。
- 外观模式（Facade Pattern）：为子系统中的一组接口提供一个统一的接口，以简化系统的使用。
3. 行为型模式（Behavioral Patterns）：- 策略模式（Strategy Pattern）：定义一系列算法，将每个算法封装起来，并使它们可以相互替换。
- 模板方法模式（Template Method Pattern）：定义一个算法的骨架，由子类实现具体步骤。
24种设计模式
24种设计模式Factory Pattern(⼯⼚模式)：1. 创建对象的接⼝，封装对象的创建；2. 使具体化类的⼯作延迟到⼦类中。
（维护⼀类对象）AbstractFactory Pattern(抽象⼯⼚模型)：该模式将⼀组对象的创建封装到⼀个⽤于创建对象的类中。
（解决的问题：要创建⼀组或者相互依赖的对象）。
Singleton Pattern(单例模式)：该模式在⾯向纯粹的⾯向对象的范式中⽤于创建唯⼀的实例，值得注意的是Singleton不能被实例化，因此将其构造函数声明为protected或private类型。
Singleton Pattern经常与Factory Pattern结合使⽤，因为Factory对象只能有⼀个。
Builder Pattern(创建者模式)：将⼀个复杂的对象的构建与它的表⽰分离，使得同样的构建构成可以创建不同的表⽰。
如建筑师画图纸，⽽⼯⼈建造房屋。
Prototype Pattern(原型模式)：提供⼀个通过已存在对象进⾏新对象创建的接⼝（clone）。
（浅拷贝和深拷贝）Bridge Pattern(桥梁模式)：将抽象部分与实现部分分开实现，使他们都可以独⽴地变化，并使⽤组合的⽅式将多维度的抽象⽅法联系在⼀起。
⽐如咖啡分⼩杯、中杯、⼤杯以及加奶和不加奶，则抽象部分为：⼩杯、中杯、⼤杯，⾏为为：加奶和不加奶。
Adapter Pattern(适配器模式)：适配就是由“源”到“⽬标”的适配，⽽当中链接两者的关系就是适配器。
它负责把“源”过度到“⽬标”。
将⼀个类的接⼝转换成客户希望的另外⼀个接⼝。
Adapter模式使得原本由于接⼝不兼容⽽不能⼀起⼯作的那些类可以⼀起⼯作。
适配器模式分为两种：①⾯向类的设计模式；②⾯向对象的设计模式。
①⾯向类的适配器：该模式使⽤继承和接⼝实现的⽅式复⽤需要适配器的类。
②⾯向对象的适配器：该模式使⽤组合的⽅式实现需要复⽤的类。
Decorator模式（装饰模式）：动态地给⼀个对象添加⼀些额外的职责。
设计模式 菜鸟教程
设计模式菜鸟教程
设计模式是软件开发中常用的解决问题的方法。
它提供了一套经过验证的、可复用的设计原则和模式，能够帮助开发人员在设计和实现软件时更加有效地解决复杂的问题。
以下是一些常见的设计模式：
1. 单例模式：保证一个类只有一个实例，并提供全局访问点。
2. 工厂模式：封装对象的创建过程，通过工厂方法创建对象。
3. 抽象工厂模式：提供一个接口，用于创建一系列相关的对象。
4. 建造者模式：将一个复杂对象的构建过程与其表示相分离，使得同样的构建过程可以创建不同的表示。
5. 原型模式：通过复制已有对象的方式创建新的对象。
6. 适配器模式：将一个类的接口转换成客户希望的另一个接口。
7. 装饰器模式：在不改变原有对象的基础上，动态地给对象添加功能。
8. 代理模式：为其他对象提供一种代理以控制对这个对象的访问。
9. 外观模式：提供一个统一的接口，用来访问子系统中的一群接口。
10. 观察者模式：定义对象间的一种一对多的依赖关系，当一
个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
这些设计模式在软件开发过程中具有重要的作用，可以提高代码的可复用性、拓展性和可维护性。
23种设计模式的经典运用
23种设计模式的经典运用介绍设计模式是解决软件设计中常见问题的可重复使用的解决方案。
本文将介绍23种经典的设计模式，并给出它们在实际开发中的应用示例。
通过学习这些设计模式，您将增加对软件设计的理解，并能够更好地解决问题。
创建型设计模式1.工厂方法模式（F a c t o r y M e t h o d）工厂方法模式通过定义一个创建对象的接口，但由子类决定实例化具体类。
这种方法可以延迟实例化过程，具有更高的灵活性和可扩展性。
应用场景：-在一个系统中，希望客户端与具体类的实例化解耦。
-希望通过增加具体类的扩展来增加系统的灵活性。
2.抽象工厂模式（A b s t r a c t F a c t o r y）抽象工厂模式提供一个接口，用于创建相关或依赖对象组。
这种模式将对象的实例化推迟到子类中，从而实现了解耦。
应用场景：-当一个系统独立于其产品的创建、组合和表示时。
-当需要一个系列的相互依赖的对象而无需指定其具体类时。
3.单例模式（S i n gl e t o n）单例模式确保一个类只有一个实例，并提供一个全局访问点。
这种模式常用于控制对资源的访问，例如数据库连接或日志文件。
应用场景：-当需要一个类的唯一实例，并且该实例需要被多个客户端共享时。
-当需要限制系统中特定类的实例数量时。
4.原型模式（P r o to t y p e）原型模式通过复制现有对象来创建新对象。
这种模式对于创建需要消耗大量资源的对象非常有用，可以通过克隆现有对象来提高性能。
应用场景：-当一个系统的某些对象的创建比较昂贵时。
-当需要避免构造函数调用，而直接通过复制现有对象来创建新对象时。
5.建造者模式（B ui l d e r）建造者模式将一个复杂对象的构建过程与其表现分离，使得相同的构建过程可以创建不同的表现。
应用场景：-当想要构建一些复杂对象时，如生成器。
-当需要创建对象的过程具有多个步骤，并且每个步骤都可以按需选择或省略时。
结构型设计模式6.适配器模式（A da p t e r）适配器模式将一个类的接口转换为客户端所期望的另一个接口。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
使用设计模式来提高程序库的重复利用性是大型程序项目开发必须的。
但是在“四人帮”的设计模式概述中提到了23种标准设计模式，不但难以记住，而且有些设计模式更多的适用于应用程序开发，对游戏项目引擎设计并没有很多的利用价值。
根据经验，精挑细选后，笃志在这里记录一些自认为有利用价值的设计模式，以便之后自己设计时使用。
一：观察者Observer观察者的设计意图和作用是：它将对象与对象之间创建一种依赖关系，当其中一个对象发生变化时，它会将这个变化通知给与其创建关系的对象中，实现自动化的通知更新。
游戏中观察者的适用环境有：1：UI控件管理类。
当我们的GUI控件都使用观察者模式后，那么用户的任何界面相关操作和改变都将会通知其关联对象——我们的UI事件机。
2：动画管理器。
很多时候我们在播放一个动画桢的时候，对其Frame有很大兴趣，此时我们设置一个FrameLister对象对其进行监视，获得我们关心的事件进行处理是必须的。
观察者伪代码：//——// 被观察对象目标类Class Subject{// 对本目标绑定一个观察者 Attach（ Observer ）；// 解除一个观察者的绑定 DeleteAttach（ Observer ）；// 本目标发生改变了，通知所有的观察者，但没有传递改动了什么Notity（）{For （…遍历整个ObserverList …）{ pObserver ->Update（）； }}// 对观察者暴露的接口，让观察者可获得本类有什么变动GetState（）；}//——// 观察者/监听者类Class Observer{// 暴露给对象目标类的函数，当监听的对象发生了变动，则它会调用本函数通知观察者Void Update （）{pSubject ->GetState（）； // 获取监听对象发生了什么变化TODO：DisposeFun（）； // 根据状态不同，给予不同的处理}}//——非程序语言描述：A是B的好朋友，对B的行为非常关心。
B要出门，此时A给了B一个警报器，告诉B说：“如果你有事，立刻按这个警报器告诉我。
”。
结果B在外面遇上了麻烦，按下警报器（Update（）），B就知道A出了事，于是就调查一下B到底遇到了什么麻烦（GetState（）），当知道B原来是因为被人打了，于是立刻进行处理DisposeFun（），派了一群手下帮B打架。
当然关心A的人可以不止一个，C，D可能也对A很关心，于是A这里保存一个所有关心它的人的链表，当遇到麻烦的时候，轮流给每个人一份通知。
二：单件模式Singleton单件模式的设计意图和作用是：保证一个类仅有一个实例，并且，仅提供一个访问它的全局访问点。
游戏中适用于单件模式的有：1：所有的Manger.在大部分的流行引擎中都存在着它的影子，例如SoundManager，ParticeManager等。
2：大部分的工厂基类。
这一点在大部分引擎中还是见不到的，实际上，我们的父类工厂采用唯一实例的话，我们子类进行扩展时也会有很大方便。
单件模式伪代码：//——Class Singleton{Static MySingleton； // 单件对象，全局唯一的。
Static Instance（）{ return MySingleton；} // 对外暴露接口}//——三：迭代器Iterator迭代器设计意图和作用是：提供一个方法，对一个组合聚合对象内各个元素进行访问，同时又不暴露该对象类的内部表示。
游戏中适用于迭代器模式的有：因为STL的流行，这个设计已经广为人知了，我们对任何形式的资源通一管理时，不免会将其聚合起来，或者List，或者Vector，我们都需要一个对其进行访问的工具，迭代器无疑是一个利器。
迭代器伪代码：//——// 迭代器基类Class Iterator{Virtual First（）；Virtual Next（）；Virtual End（）；Virtual CurrentItem（）； // 返回当前Item信息}//——// 聚合体的基类Class ItemAggregate{Virtual CreateIterator（）； // 创建访问自身的一个迭代器}//——// 实例化的项目聚合体Class InstanceItemAggregate ： public ItemAggregate{CreateIterator（）{ return new InstanceIterator（this）； }}//——四：访问者模式Visitor：访问者设计意图和作用是：当我们希望对一个结构对象添加一个功能时，我们能够在不影响结构的前提下，定义一个新的对其元素的操作。
（实际上，我们只是把对该元素的操作分割给每个元素自身类中实现了而已）游戏中适用于访问者模式的有：任何一个比较静态的复杂结构类中都适合采用一份访问者。
这里的“比较静态的复杂结构类”意思是，该结构类中元素繁多且种类复杂，且对应的操作较多，但类很少进行变化，我们就能够将，对这个结构类元素的操作独立出来，避免污染这些元素对象。
1：例如场景管理器中管理的场景节点，是非常繁多的，而且种类不一，例如有Ogre中的Root， Irrchit中就把摄象机，灯光，Mesh，公告版，声音都做为一种场景节点，每个节点类型是不同的，虽然大家都有共通的Paint（），Hide（）等方法，但方法的实现形式是不同的，当我们外界调用时需要统一接口，那么我们很可能需要需要这样的代码Hide（ Object ）{ if （Object == Mesh） HideMesh（）； if （Object == Light） HideLight （）；… }此时若我们需要增加一个Object新的类型对象，我们就不得不对该函数进行修正。
而我们可以这样做，让Mesh，Light他们都继承于Object，他们都实现一个函数Hide（），那么就变成Mesh：：Hide（ Visitor ） { Visitor.Hide （Mesh）； }Light：：Hide（Visitor ）{ Visitor.Hide （Light）； }我们在调用时只需要Object.Hide（Visitor）{ return Visitor.Hide （Object）； }这样做的好处，我们免去了对重要函数的修正，Object.Hide（Visitor）{}函数我们可以永久不变，但是坏处也是很明显的，因为将方法从对象集合结构中抽离出来，就意味着我们每增加一个元素，它必须继承于一个抽象的被访问者类，实现其全部函数，这个工作量很大。
所以，访问者是仅适合于一个装载不同对象的大容器，但同时又要求这个容器的元素节点不应当有大的变动时才使用。
另外，废话一句，访问者破坏了OO思想的。
访问者伪代码：//——// 访问者基类Class Visitor{Virtual VisitElement（ A ）{ … }； // 访问的每个对象都要写这样一个方法Virtual VisitElement（ B ）{ … }；}// 访问者实例AClass VisitorA{VisitElement（ A ）{ … }； // 实际的处理函数VisitElement（ B ）{ … }； // 实际的处理函数}// 访问者实例BClass VisitorB{VisitElement（ A ）{ … }； // 实际的处理函数VisitElement（ B ）{ … }； // 实际的处理函数}// 被访问者基类Class Element{Virtual Accept（ Visitor ）； // 接受访问者}// 被访问者实例AClass ElementA{Accecpt（ Visitor v ）{ v-> VisitElement（this）； }； // 调用注册到访问者中的处理函数}// 被访问者实例BClass ElementB{Accecpt（ Visitor v ）{ v-> VisitElement（this）； }； // 调用注册到访问者中的处理函数}//——五：外观模式Fa？ade外观模式的设计意图和作用是：将用户接触的表层和内部子集的实现分离开发。
实际上，这个模式是个纸老虎，之后我们看伪代码立刻就会发现，这个模式实在用的太频繁了。
游戏中需要使用外观模式的地方是：这个非常多了，举几个比较重要的。
1：实现平台无关性。
跨平台跨库的函数调用。
2：同一个接口去读取不同的资源。
3：硬件自动识别处理系统。
外观模式伪代码//——// 用户使用的接口类Class Interface{// 暴露出来的函数接口函数，有且仅有一个，但内部实现是调用了两个类Void InterfaceFun（）{// 根据某种条件，底层自主的选择使用A或B的方法。
用户无须关心底层实现If （ XXX ）{ActualA->Fun（）；}Else{ActualB->Fun（）；}}；}// 实际的实现，不暴露给用户知道Class ActualA{Void Fun（）；}// 实际的实现，不暴露给用户知道Class ActualB{Void Fun（）；}怎么样，纸老虎吧，看起来很高深摸测的命名而已。
//——六：抽象工厂模式AbstractFactory抽象工厂的设计意图和作用是：封装出一个接口，这个接口负责创建一系列互相关联的对象，但用户在使用接口时不需要指定对象所在的具体的类。
从中文命名也很容易明白它是进行批量生产的一个生产工厂的作用。
游戏中使用抽象工厂的地方有：基本上任何有批量的同类形式的子件地方就会有工厂的存在。
（补充一句：下面代码中的ConcreteFactory1实例工厂就是工厂，而抽象工厂仅仅是工厂的一个抽象层而已。
）1：例如，在音频方面，一个音频的抽象工厂派生出不同的工厂，有音乐工厂，音效工厂。
音效工厂中又有一个创建3D音效节点的方法，一个创建普通音效节点的方法。
最终用户只需要SoundFactory->Create3DNode（ pFileName ）；就可以创建一个节点了。
2：场景对象。
3：渲染对象。
4：等等……工厂与单件，管理器Manager关系一定是非常紧密的。
抽象工厂伪代码：//——class AbstractProductA {}； // 抽象的产品A基类class AbstractProductB {}； //抽象的产品B基类// 抽象工厂基类class AbstractFactory { public：virtual AbstractProductA* CreateProductA（） = 0 ；// 创建ProductA virtual AbstractProductB* CreateProductB（） = 0 ；// 创建ProductB } ；class ProductA1 ： public AbstractProductA {}； // 产品A的实例1 class ProductA2 ： public AbstractProductA {}； // 产品A的实例2class ProductB1 ： public AbstractProductB {}； // 产品B的实例1 class ProductB2 ： public AbstractProductB {}； // 产品B的实例2// 实例工厂1class ConcreteFactory1 ： public AbstractFactory { virtual AbstractProductA* CreateProductA（） { return new ProductA1（）； } virtual AbstractProductB* CreateProductB（） { return new ProductB1（）； } static ConcreteFactory1* Instance（） { } // 实例工厂尽量使用单件模式} ；// 实例工厂2。