23种设计模式(C++).pdf

1、设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 设计模式精解 GoF 23 种设计模式解析附 C+实现源码 目 录 0 引言 2 0.1 设计模式 解析（总序） .2 0.2 设计模式 解析后记 .2 0.3 与作者联 系 5 1 创建型模 式 .5 1.1 Factory模式 5 1.2 AbstactFactory模式 11 1.3 Singleton模式 .19 1.4 Builder模式 .22 1.5 Prototype模式 .29 2 结构型模 式 .33 2.1 Bridge模式 33 2.2 Adapter模式 39 2.3 Decorator模式

2、.47 2.4 Composite模式 .52 2.5 Flyweight模式 58 2.6 Facade模式 .64 2.7 Proxy模式 .70 3 行为模式 .74 3.1 Template模式 74 3.2 Strategy模式 .80 3.3 State模式 .87 3.4 Observer模式 94 3.5 Memento模式 .103 3.6 Mediator模式 108 3.7 Command模式 117 3.8 Visitor模式 126 3.9 Chain of Responsibility模式 .136 3.10 Iterator模式 .141 3.11 Interpr

3、eter模式 148 4 在开发中体 验设计模式 153 4.1 在开发中 体验设计模式 .153 4.2 深入理解 State模式附 C+实现源码 155 4.3 也谈 double dispatch(双分 派 ):Visitor 模式 162 4.4 为什么使 用设计模式从 Singleton模式谈起 164 第 1 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 5 附录 170 5.1 关于设计 模式的思考 .170 6 说明 171 0 引言 0.1设计模式解析（总序） “ Next to My Life, Softwa

4、re Is My Passion” Robert C.Martin. 懂了设 计模式，你就懂了面向对象分析和设计（ OOA/D）的精要。反之好像也可能成立。道可道，非常道。道不远人，设计模式亦然如此。 一直想 把自己的学习经验以及在项目中的应用经历拿出来和大家共享， 却总是下不了这个决心： GoF 的 23 种模式研读、总结也总需要些时日，然而时间对于我来说总是不可预计的。 之所以下了这个决心， 有两个原因： 一是 Robert 的箴言， 二 是因为我是一个感恩的人，就像常说的：长怀感恩之心，人生便无遗憾。想想当时读 GoF 的那本圣经时候的苦闷、实现 23 个模式 时候的探索、悟道后的欣悦，

5、我觉得还是有这个意义。 0.2设计模式解析后记 写完了Interpreter模式 之后，我习惯性的看看下一天的安排，却陡然发现 GoF的 23个设计模式的解析 已经在我不经意间写完了。就像在一年前看GoF的设 计模式一书，和半年前用C+模 拟 、 实 现 23种经典的设计模式一般， 透过这个写解析的过程， 我又看到了另外一个境界。 一直认为学习的过程很多时候可以这样划分： 自己学会一门知识 （技术） 、 表 达出来、 教会别人、 记录下来， 虽然这个排序未必对每个人都合适 （因为可能不同人有着不 同的特点能力） 。 学一门知识， 经过努力、 加以时日 ， 总是可以达到的， 把自己学的用自己的话

6、表达出来就必须要将学到的知识加以消化、 理解， 而教会一个不懂这门知识的人则比表达出来要难， 因为别人可能并不是适应你的表述方式， 记录下来则需要经过沉淀、 积累、 思考，最后厚积薄发，方可小成。 第 2 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 设计模式之于面向对象系统的设计和开发的作用就有如数据结构之于面向过程开发的作用一般 ， 其重要性和必要性自然不需要我赘述。 然而学习设计模式的过程却是痛苦的， 从阅读设计模式的圣经GoF 的 设计模式： 可复用面向对象软件的基础 时的枯燥、 苦闷 、茫无头绪，到有一天突然有一种顿悟

7、；自己去实现 GoF 的 23 中模式时候 的知其然不知其所以然， 并且有一天在自己设计的系统种由于设计的原因让自己苦不堪言， 突然悟到了设计模式种的某一个正好可以很好的解决问题，到自己设计的 elegant 的系统 时候的喜悦与思考；一直到最后向别人去讲解设计模式，别人向你咨询设计模式，和别人讨论设计模式。就如GoF 在其前言 中说到： 一旦你理解了设计并且有了一种 “Aha！ ” （而不 是 “ Huh？” ） 的应用经验和体验后， 你将用一种非同寻常的方式思考面向对象设计。 这个过程我认为是漫长的，painful， 但 是是非常必要的。 经过了的才是自己的， Scott Mayer 在其

8、巨著 E ffective C+就曾经说过：C+老手和 C+新手的区 别就是前者手背上有很多伤疤。是的在软件开发和设计的过程中， 失败、 错误 是最好的老师， 当然在系统开发中， 失败和错误则是噩梦的开端和结束，因为你很难有改正错误的机会。 因此，尽量让自己多几道疤痕是对的 。 面向对象系统的分析和设计实际上追求的就是两点， 一是高内聚 （Cohesion） ， 而是低耦合 （C oupling） 。 这也 是我们软件设计所准求的， 因此无论是 OO 中的 封装、 继承、 多态 ，还是我们的设计模式的原则和实例都是在为了这两个目标努力着、贡献着。 道不远人， 设计模式 也 是这般 ， 正 如我

9、在 设计模式探索 （总序） 中提到的。 设计模式并不是空的理论， 并不是脱离实际的教条。 就如我们在进行软件开发的过程会很自然用到很多的算法和结构来解决实际的问题， 那些其实也就是数据结构中的重要概念和内容。 在面向对象系统的设计和开发中， 我们已经积累了很多的原则， 比如 面向对象中的封装、 继承和多态、 面向接口编程、 优先使用组合而不是继承、 将抽象和实现分离的思想 等等， 在设计 模式中你总是能看到他们的影子， 特别是组合 （委托） 和继承的差异带来系统在耦合性上的差别， 更是在设计模式多次涉及到。 而一些设计模式的思想在我们做系统的设计和开发中则是经常要用到的，比如说Template

10、、Strategy模式 的思想，Singleton模式 的思想，Factory模式的思想等等， 还有很多的模式已经在我们的开发平台中扎根了， 比如说Observer （其实例为M odelC ontrolVie w模式） 是MFC和Struts中 的基本框架， Iterator模 式则在C+的 STL中有实现等。 或许有的人会说， 我们不需要设计模式， 我们的系统很小， 设计模式会束缚 我们的实现。 我想说的是， 设计模式体现的是一种思想， 而思想则是指导行为的一切， 理解 和掌握了设计模式，并不是说记住了 23 种（或更多 ）设计场景和解决策略（实际上这也是很第 3 页 共 171 页 k_

11、eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 重要的一笔财富） ， 实际接受的是一种思想的熏陶和洗礼， 等这种思想融入到了你的思想中后，你就会不自觉地使用这种思想去进行你的设计和开发，这一切才是最重要的 。 之于学习设计模式的过程我想应该是一个 迭代 的过程， 我向来学东西的时候不追求一遍就掌握、 理解透彻 （很多情况也是不可能的） ， 我喜欢用一种迭代的思想来指导我的学习过程。 看书看不懂、 思想没有理解， 可以反复去读、 去思考， 我认为这样一个过程是适合向我们不是有一个很统一的时间去学习一种技术和知识 （可能那样有时候反而有些枯燥和郁闷） 。Go

12、F 在 设计模式 一书中也提到， 如果不是一个有经验的面向对象设计人员， 建议从最简单最常用的设计模式入门，比如 AbstractFactory 模式、Ad apater 模式、 Composite 模 式、Decorator 模 式、Factory 模式、Observ er 模式、Strategy 模 式 、 Template模式等。我的感触是确实是这样， 至少 GoF 列 出 的模式我都在开发和设计有用到， 如果需要我这里再加上几个我觉得在开发中会很有用的模式：Singleton 模式、 Faade 模式和 Bridge 模式。 写设计模式解析的目的其实是想把 GoF 的 设计 模式 进行

13、简化， 变得容易理解和接受 。GoF 的 设计 模式 是圣经， 但是同时因为 设计模式 一书是 4 位 博 士的作品， 并且主 要是基于 Erich 的博士论文 ， 博士的特色我觉得最大的就是抽象， 将一个具体的问题抽象到一般， 形成理论。 因此 GoF 的这本圣经 在很多地方用语都比较精简和抽象， 读过的可能都有一种确实是博士写出来的东西的感觉。 抽象的好处是能够提供指导性的意见和建议， 其瑕疵就是不容易为新手所理解和掌握。 我的本意是想为抽象描述和具体的实现提供一个桥接 （尽管GoF 在书中给 出了很多的代码和实例， 但是我觉得有两个不足： 一是 不完整 ， 结果是不好 直接看到演示， 因

14、此我给出的代码都是完整的、 可编译运行的； 二是给出的都是一些比较大的系统中一部分简单实现， 我想 GoF 的 原意可能是想说明这些模式确实很管用， 但是却同时带来一个更大的不好的地方就是 不容易为新手理解和掌握 ），然 而 这个过程是痛苦的， 也可能是不成功的 （可能会是这样）。这里面就有一个取舍的问题，一方面我想尽量去简化 GoF的描述， 然而思考后的东西却在很多的时候和 GoF 的描述很相 似， 并且觉得将这些内容再抽象一下，书中的很多表达则是最为经典的。当然这里面也有些许的例外，Bruce Eckel 在其大作Thinking in Patterns一书中 提到：Bridge 模式是

15、GoF在描述其 23中设计模 式 中描述得最为糟糕得模式，于我心有戚戚焉！具体的内容请参看我写的设计模式解析Bridge 模式 一文。另外一方面，我又要尽量去避免走到了 GoF 一 起 ，因为那样就失去了我写这个解析的本意了。 这两个方面的权衡是很痛苦， 并且结果可能也还是没有达到我的本意要求。 第 4 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 4 月份是我最 不忙的时候， 也是我非常忙的时候。 论文的查阅、 思考、 撰写， 几个项目的前期准备 （文档、 Demo等） ， 俱乐部的诸多事宜， 挑战杯的准备， 学习 （课业、

16、专业等各个方面）等等，更加重要的是 Visual CMCS（ Visual C_minus Compiler System） 的设计和开发（Visual CMCS是笔者设计和开发的C _minus语言（ C的子集）的编译系统，系统操作界面类似VC，并且准备 代码分发和共享，详细信息请参考Visual CMCS的网站和Blog中的相关信息的发布）， Visual CMCS1.0(Beta)终于在 4 月底发 布了 ，也在别人的帮助下构建了V isual CMCS的网站 （ http:/ ） 。 之 所以提及这个， 一方面是 在Visual CMCS的设计和开发体验了很多的设计模式，比如Facto

17、ty模式、 Singleton模 式、Strategy模式 、State模式等 等（我有一篇Blog中有 关于这个的不完全的描述）；另外一方面是这个设计模式解析实际上在这些工作的间隙中完成的， 我一般会要求自己每天写一个模式， 但是特殊的时候可能没有写或者一天写了不止一个。 写这些文章， 本身没有任何功利的杂念， 只是一个原生态的冲动， 反而很轻松的完成了 。 有心栽花未必发， 无心之事可成功， 世间的事情可 能在很多的时候恰恰就是那样了。 最后想用自己在阅读、 学习、 理解、 实现、 应用、 思考设计模式后的一个感悟结束这个后记：只有真正理解了设计模式，才知道什么叫面向对象分析和设计。 k_

18、eckel 写毕 于 2005-05-04（五四青年 节） 1： 01 0.3 与作者联系 Author K_Eckel State Candidate for Masters Degree School of Computer Wuhan University E_mail 1 创建型模式 1.1 Factory模式 问题 在面向对象系统设计中经常可以遇到以下的两类问题： 第 5 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 1）为了提高 内聚（ Cohesion）和松耦合（ Coupling） ，我们经常 会抽象出一 些类

19、的公 共接口以形成抽象基类或者接口。 这样我们可以通过声明一个指向基类的指针来指向实际的子类实现， 达到了多态的目的。 这里很容易出现的一个问题 n 多的子类继 承自抽象基类， 我们不得不在每次要用到子类的地方就编写诸如 new ;的 代码。这里带来两个问题 1）客户程序员必须知道实际子类的名称 （当系统复杂后， 命名将是一个很不好处理的问题， 为了处理可能的名字冲突， 有的命名可能并不是具有很好的可读性和可记忆性， 就姑且不论不同程序员千奇百怪的个人偏好了。 ） ， 2）程序的扩展性和维护变得越来越困难。 2）还有一种 情况就是在 父类中并不 知道具体要 实例化哪一 个具体的子 类。这里的

20、意 思为：假设我们在类 A 中要使用到类 B， B 是一个 抽象父类，在 A 中并不知道具体要实例化那一个 B 的 子类， 但是在类 A 的子类 D 中是可以知道的。 在 A 中我们没有办法直接使用类似于 new 的语句，因为根本就不知道是什么。 以上两个问题也就引出了 Factory 模 式的两个最重要的功能： 1）定义创建 对象的接口，封装了对象的创建； 2）使得具体 化类的工作延迟到了子类中。 模式选择 我们通常使用 Factory 模 式来解决上面给出的两个问题。在第一个问题中，我们经常就是声明一个创建对象的接口，并封装了对象的创建过程。 Factory 这里类似于一个真正意义上的工厂

21、（ 生产对象） 。 在第二个问 题中，我们 需要提供一 个对象创建 对象的接口 ，并在子类中提供其具体实现（因为只有在子类中可以决定到底实例化哪一个类） 。 第一中情况的 Factory 的 结构示意图为： 第 6 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 图 1： Factory 模式结构示意图 1 图 1 所以 的 Factory 模式 经常在系统开发中用到，但是这并不是 Factory 模式的最大威力所在 （因为这可以通过其他方式解决这个问题） 。 Factory 模式不单是提供了创建对象的接口，其最重要的是延迟了子类

22、的实例化（第二个问题） ，以 下是这种情况的一个 Factory 的结构示意图： 图 2： Factory 模式结构示意图 1 图 2 中关键 中 Factory 模 式的应用并不是只是为了封装对象的创建，而是要把对象的创建放到子类中实现： Factory 中只是提供了对象创建的接口，其实现将放在 Factory 的子类ConcreteFactory 中进行。这是图 2 和图 1 的区别 所在。 实现 完整代码示例（ code） Factory 模式的实现比较简单，这里为了方便初学者的学习和参考，将给出完整的实现代码（所有代码采用 C+实现，并在 VC 6.0 下测 试运行） 。 代码片 断

23、1： Product.h /Product.h #ifndef _PRODUCT_H_ #define _PRODUCT_H_ class Product public: virtual Product() =0; 第 7 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ protected: Product(); private: ; class ConcreteProduct:publicProduct public: ConcreteProduct(); ConcreteProduct(); protected: privat

24、e: ; #endif /_PRODUCT_H_ 代码片断 2： Product.cpp /Product.cpp #include “Product.h“ #include using namespace std; Product:Product() Product:Product() ConcreteProduct:ConcreteProduct() cout using namespace std; Factory:Factory() Factory:Factory() ConcreteFactory:ConcreteFactory() cout using namespace std;

25、 int main(int argc,char* argv) Factory* fac = new ConcreteFactory(); Product* p = fac-CreateProduct(); return 0; 第 10 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 代码说明 示例代码中给出的是 Factory 模式解 决父类中并不知道具体要实例化哪一个具体的子类的问题，至 于为创建对 象提供接口 问题，可以 由 Factory 中附加相应 的创建操作 例 如Create*Product（）即可 。具体请参加讨论内

26、容。 讨论 Factory 模式在实际开发中应用非常广泛，面向对象的系统经常面临着对象创建问题：要创建的类实在是太多了。而 Factory 提供的创 建对象的接口封装（第一个功能） ， 以及其将类的实例化推迟到子类 （第二个功能） 都部分地解决了实际问题。 一个简单的例子就是笔者开开发 VisualCMCS 系 统的语义分析过程中， 由于要为文法中的每个非终结符构造一个类处理，因此这个过程中对象的创建非常多，采用 Factory 模 式后系统可读性性和维护都变得elegant 许多 。 Factory模式也带来至少以下两个问题： 1） 如果为每一个具体的 ConcreteProduct 类的

27、实例化提供一个函数体， 那么我们可能不得不在系统中添加了一个方法来处理这个新建的 ConcreteProduct，这样 Factory 的接口永远就不肯能封闭 （ Close） 。 当然我们可以通过创建一个 Factory 的子类来通过多态实现这一点，但是这也是以新建一个类作为代价的。 2）在实 现中我们可以通过参数化工厂方法，即给 FactoryMethod（ ）传递一个参数用以决定是创建具体哪一个具体的 Product（实际上笔 者在 VisualCMCS 中也正 是这样做的） 。当然也可以通过模板化避免 1）中的子 类创建子类，其方法就是将具体 Product 类作为 模板参数，实现起来

28、也很简单。 可以看出， Factory 模式对于对 象的创建给 予开发人员 提供了很好 的实现策略 ，但 是Factory 模式 仅仅局限于一类类（就是说 Product 是一类，有一个共同的基类） ，如果 我们要为不同类的类提供一个对象创建的接口，那就要用 AbstractFactory 了。 1.2 AbstactFactory模式 问题 假设我们要开发一款游戏， 当然为了吸引更多的人玩， 游戏难度不能太大 （让大家都没有信心了， 估计游戏也 就没有前途 了） ，但是也 不能太简单 （没有挑战 性也不符合 玩家的心第 11 页 共 171 页 k_eckel 设计模式精解 GoF 23 种

29、设 计模式解析附 C+实现源码 http:/ 理） 。于是我 们就可以采 用这样一种 处理策略： 为游戏设立 等级，初级 、中级、高 级甚至有BT 级。 假设 也是过关的游戏， 每个关卡都有一些怪物 （ monster） 守着， 玩家要把这 些 怪物干掉才可以过关。 作为开发者， 我们就不得不创建怪物的类， 然后初级怪物、 中级怪物等 都继承自怪物 类（当然不 同种类的则 需要另创建 类，但是模 式相同） 。在 每个关卡， 我们都要创建怪物的 实例，例如 初级就创建 初级怪物（ 有很多种类） 、中级创建 中级怪物等 。可以想象在这个系统中， 将会有成千上万的怪物实例要创建， 问题是还要保证创建

30、的时候不会出错：初级不能创建 BT 级的 怪物（玩家就郁闷了，玩家一郁闷，游戏也就挂挂了） ，反 之也不可以。 AbstractFactory 模式就是用来解决这类问题的：要创建 一组 相关或者相互依赖的对象。 模式选择 AbstractFactory 模式典型的结构图为： 图 2-1： AbstractFactory Pattern 结构图 AbstractFactory 模式关 键 就是将这 一 组对象的 创 建封装到 一 个用于创 建 对象的 类（ ConcreteFactory） 中， 维护这样一个创建类总比维护 n 多相 关对象的创建过程要简单的多。 实现 第 12 页 共 171

31、页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 完整代码示例（ code） AbstractFactory 模式的实现比较简单， 这里为了方便初学者的学习和参考， 将给出完整的实现代码（所有代码采用 C+实 现，并在 VC 6.0 下测试运 行） 。 代码片断 1： Product.h /Product.h #ifndef _PRODUCT_H_ #define _PRODUCT_H_ class AbstractProductA public: virtual AbstractProductA(); protected: AbstractPro

32、ductA(); private: ; class AbstractProductB public: virtual AbstractProductB(); protected: AbstractProductB(); private: ; class ProductA1:public AbstractProductA public: ProductA1(); ProductA1(); protected: private: 第 13 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ ; class ProductA2:public

33、 AbstractProductA public: ProductA2(); ProductA2(); protected: private: ; class ProductB1:public AbstractProductB public: ProductB1(); ProductB1(); protected: private: ; class ProductB2:public AbstractProductB public: ProductB2(); ProductB2(); protected: private: ; #endif /_PRODUCT_H_ 代码片断 2： Produc

34、t.cpp /Product.cpp 第 14 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ #include “Product.h“ #include using namespace std; AbstractProductA:AbstractProductA() AbstractProductA:AbstractProductA() AbstractProductB:AbstractProductB() AbstractProductB:AbstractProductB() ProductA1:ProductA1() cou

35、t using namespace std; AbstractFactory:AbstractFactory() AbstractFactory:AbstractFactory() 第 17 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ ConcreteFactory1:ConcreteFactory1() ConcreteFactory1:ConcreteFactory1() AbstractProductA* ConcreteFactory1:CreateProductA() return new ProductA1();

36、AbstractProductB* ConcreteFactory1:CreateProductB() return new ProductB1(); ConcreteFactory2:ConcreteFactory2() ConcreteFactory2:ConcreteFactory2() AbstractProductA* ConcreteFactory2:CreateProductA() return new ProductA2(); AbstractProductB* ConcreteFactory2:CreateProductB() return new ProductB2();

37、代码片断 5： main.cpp /main.cpp 第 18 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ #include “AbstractFactory.h“ #include using namespace std; int main(int argc,char* argv) AbstractFactory* cf1 = new ConcreteFactory1(); cf1-CreateProductA(); cf1-CreateProductB(); AbstractFactory* cf2 = new Concr

38、eteFactory2(); cf2-CreateProductA(); cf2-CreateProductB(); return 0; 代码说明 AbstractFactory 模式的实现代码很简单， 在测试程序中可以看到， 当我们要创建一组对象（ ProductA1， ProductA2）的 时候 我们只 用维 护一个 创建 对象（ ConcreteFactory1） ，大大简化了维护的成本和工作。 讨论 AbstractFactory 模式和 Factory 模式的 区别是初学（使用）设计模式时候的一个容易引起困惑的地方。 实际上， AbstractFactory 模式是为创建 一组 （

39、 有 多类） 相关或依赖的对象提供创建接口， 而 Factory 模式正如我在相应的文档中分析的是为 一类 对 象提供创建接口或延迟对象的创建到子类中实现。并且可以看到， AbstractFactory 模式通常都是使用 Factory 模式实现（ ConcreteFactory1） 。 1.3 Singleton模式 问题 个人认为 Singleton 模式 是设计模式中最为简单、最为常见、最容易实现，也是最应该熟悉和掌握的模式。 且不说公司企业在招聘的时候为了考察员工对设计的了解和把握， 考的最多的就是 Singleton 模式 。 Singleton 模式解决问题 十分常见， 我们怎样去

40、 创建一个唯 一的变量（ 对象）？在 基于第 19 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ 对象的设计中我们可以通过创建一个全局变量 （对象） 来实现， 在面向对象和面向过程结合的设计范式 （如 C+中） 中， 我们也还是可以通过一个全局变量实现这一点。 但是当我们遇到了纯粹的面向对象范式中，这一点可能就只能是通过 Singleton 模式 来实现了，可能这也正是很多公司在招聘 Java 开发人员时 候经常考察 Singleton 模式 的缘故吧。 Singleton 模 式在开发中非常有用，具体使用在讨论给出。 模式选择

41、 Singleton 模 式典型的结构图为： 图 2-1： Singleton Pattern 结构图 在 Singleton 模式的结 构图中可以看到，我们通过维护一个 static 的成 员变量来记录这 个唯一的对象实例。通过提供一个 staitc 的接口 instance 来获 得这个唯一的实例。 实现 完整代码示例（ code） Singleton 模式的实很简 单，这里为 了方便初学 者的学习和 参考，将给 出完整的实 现代码（所有代码采用 C+实现，并在 VC 6.0 下测 试运行） 。 代码片断 1： Singleton.h /Singleton.h #ifndef _SINGL

42、ETON_H_ #define _SINGLETON_H_ #include using namespace std; class Singleton public: static Singleton* Instance(); protected: 第 20 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ Singleton(); private: static Singleton* _instance; ; #endif /_SINGLETON_H_ 代码片断 2： Singleton.cpp /Singleton.cpp #i

43、nclude “Singleton.h“ #include using namespace std; Singleton* Singleton:_instance = 0; Singleton:Singleton() cout using namespace std; int main(int argc,char* argv) Singleton* sgn = Singleton:Instance(); 第 21 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/ return 0; 代码说明 Singleton 模 式的实现无须补充

44、解释，需要说明的是， Singleton 不可以被 实例化，因此我们将其构造函数声明为 protected 或者直接声明为 private。 讨论 Singleton 模式在开发中 经常用到， 且不说我们 开发过程中 一些变量必 须是唯一的 ，比如说打印机的实例等等。 Singleton 模 式经常和 Factory（ AbstractFactory） 模式在一起使用， 因为系统中工厂对象一般来说只要一个，笔者在开发 Visual CMCS 的时候，语义分析过程（以及其他过程）中都用到工厂 模式来创建 对象（对象 实在是太多 了） ，这里的工厂对象实 现就是同时 是一个Singleton 模

45、式的实例，因为系统我们就只要一个工厂来创建对象就可以了。 1.4 Builder模式 问题 生活中有着很多的 Builder的例子， 个人觉得大学生活就是一个 Builder模 式的最好体验：要完成大学教育， 一般将大学教育过程分成 4 个 学期进行， 因此没有学习可以看作是构建完整大学教育的一个部分构建过程， 每个人经过这 4 年的 （ 4 个阶段） 构建过程得到的最后的结果不一样， 因为可能在四个阶段的构建中引入了很多的参数 （每个人的机会和际遇不完全相同） 。 Builder 模式 要解决的也 正是这样的 问题：当我 们要创建的 对象很复杂 的时候（通 常 是由很多其他 的对象组合 而成） ，我们 要要复杂对 象的创建过 程和这个对 象的表示（ 展示）分离开来， 这样做的好处就是通过一步步的进行复杂对象的构建， 由于在每一步的构造过程中可以引入参数，使得经过相同的步骤创建最后得到的对象的展示不一样。 模式选择 Builder 模式 的典型结构图为： 第 22 页 共 171 页 k_eckel 设计模式精解 GoF 23 种设 计模式解析附 C+实现源码 http:/www.mscenter.