GoF 23种设计模式解析附 C＋＋实现源码.pdf

设计模式精解一GoF 23种设计模式解析附C+实现源码 设计模式精解一GoF23种设计模式解析附C+实现源码目录0弓I言.20.1设计模式解析（总序）.20.2设计模式解析后记.20.3与作者联系.51创建型模式.51.1 Factory 模式.51.2 AbstactFactory 模式.111.3 Singleton模式.191.4 Builder模式.221.5 Prototype模式.292结构型模式.332.1 Bridge 模式.332.2 Adapter 模式.392.3 Decorator模式.472.4 Composite模式.522.5 Fly weight 模式.582.6 Facade模式.642.7 Proxy模式.703行为模式.743.1 Template 模式.743.2 Strategy模式.803.3 State模式.873.4 Observer模式.943.5 Memento模式.1033.6 Mediator模式.1083.7 Command模式.1173.8 Visitor模式.1263.9 Chain of Responsibility模式.1363.10 Iterator模式.1413.11 Interpreter 模式.1484在开发中体验设计模式.1534.1 在开发中体验设计模式.1534.2 深入理解State模式附C+实现源码.1554.3 也谈double dispatch（双分派）:Visitor 模式.1624.4 为什么使用设计模式-从Singleton模式谈起.164第1页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 5附录.1705.1关于设计模式的思考.1706说明.1710引言0.1设计模式解析（总序）“Next to My Life,Software Is My Passion”-Robert C.Martin.懂了设计模式，你就懂了面向对象分析和设计（00A/D）的精要。反之好像也可能成 立。道可道，非常道。道不远人，设计模式亦然如此。一直想把自己的学习经验以及在项目中的应用经历拿出来和大家共享,却总是下不了这 个决心：GoF的23种模式研读、总结也总需要些时日，然而时间对于我来说总是不可预计 的。之所以下了这个决心，有两个原因：一是Robert的箴言，二是因为我是一个感恩的人,就像常说的：长怀感恩之心，人生便无遗憾。想想当时读GoF的那本圣经时候的苦闷、实 现23个模式时候的探索、悟道后的欣悦，我觉得还是有这个意义。0.2设计模式解析后记写完了Interpreter模式之后，我习惯性的看看下一天的安排，却陡然发现GoF的23个 设计模式的解析已经在我不经意间写完了。就像在一年前看GoF的设计模式一书，和半 年前用C+模拟、实现23种经典的设计模式一般，透过这个写解析的过程，我又看到了另外 一个境界。一直认为学习的过程很多时候可以这样划分：自己学会一门知识（技术）、表达 出来、教会别人、记录下来，虽然这个排序未必对每个人都合适（因为可能不同人有着不同 的特点能力）。学一门知识，经过努力、加以时日，总是可以达到的，把自己学的用自己的 话表达出来就必须要将学到的知识加以消化、理解，而教会一个不懂这门知识的人则比表达 出来要难，因为别人可能并不是适应你的表述方式，记录下来则需要经过沉淀、积累、思考,最后厚积薄发，方可小成。第2页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 设计模式之于面向对象系统的设计和开发的作用就有如数据结构之于面向过程开发的 作用一般，其重要性和必要性自然不需要我赘述。然而学习设计模式的过程却是痛苦的，从 阅读设计模式的圣经GoF的设计模式：可复用面向对象软件的基础时的枯燥、苦闷、茫无头绪，到有一天突然有一种顿悟；自己去实现GoF的23中模式时候的知其然不知其所 以然，并且有一天在自己设计的系统种由于设计的原因让自己苦不堪言，突然悟到了设计模 式种的某一个正好可以很好的解决问题，到自己设计的elegant的系统时候的喜悦与思考；一直到最后向别人去讲解设计模式，别人向你咨询设计模式，和别人讨论设计模式。就如 GoF在其前言中说到：一旦你理解了设计并且有了一种“Aha!”（而不是“Huh?”）的应 用经验和体验后，你将用一种非同寻常的方式思考面向对象设计。这个过程我认为是漫长的，painful,但是是非常必要的。经过了的才是自己的，Scott Mayer在其巨著Effective C+就曾经说过：C+老手和C+新手的区别就是前者手背上有很多伤疤。是的在软件开发和设 计的过程中，失败、错误是最好的老师，当然在系统开发中，失败和错误则是噩梦的开端和 结束，因为你很难有改正错误的机会。因此，尽量让自己多几道疤痕是对的。面向对象系统的分析和设计实际上追求的就是两点，一是高内聚（Cohesion）,而是低 耦合（Coupling）o这也是我们软件设计所准求的，因此无论是00中的封装、继承、多态，还是我们的设计模式的原则和实例都是在为了这两个目标努力着、贡献着。道不远人，设计模式也是这般，正如我在设计模式探索（总序）中提到的。设计模 式并不是空的理论，并不是脱离实际的教条。就如我们在进行软件开发的过程会很自然用到 很多的算法和结构来解决实际的问题，那些其实也就是数据结构中的重要概念和内容。在面 向对象系统的设计和开发中，我们已经积累了很多的原则，比如面向对象中的封装、继承和 多态、面向接口编程、优先使用组合而不是继承、将抽象和实现分离的思想等等，在设计模 式中你总是能看到他们的影子，特别是组合（委托）和继承的差异带来系统在耦合性上的差 别，更是在设计模式多次涉及到。而一些设计模式的思想在我们做系统的设计和开发中则是 经常要用到的，比如说Template、Strategy模式的思想，Singleton模式的思想，Factory 模式的思想等等，还有很多的模式已经在我们的开发平台中扎根了，比如说Observer（其实 例为Model ControlView模式）是MFC和Struts1的基本框架，Iterator模式则在C+的STL 中有实现等。或许有的人会说，我们不需要设计模式，我们的系统很小，设计模式会束缚我 们的实现。我想说的是，设计模式体现的是一种思想，而思想则是指导行为的一切，理解和 掌握了设计模式，并不是说记住了 23种（或更多）设计场景和解决策略（实际上这也是很 第3页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 重要的一笔财富），实际接受的是一种思想的熏陶和洗礼，等这种思想融入到了你的思想中 后，你就会不自觉地使用这种思想去进行你的设计和开发，这一切才是最重要的。之于学习设计模式的过程我想应该是一个迭代的过程，我向来学东西的时候不追求一遍 就掌握、理解透彻（很多情况也是不可能的），我喜欢用一种迭代的思想来指导我的学习过 程。看书看不懂、思想没有理解，可以反复去读、去思考，我认为这样一个过程是适合向我 们不是有一个很统一的时间去学习一种技术和知识（可能那样有时候反而有些枯燥和郁闷）。GoF在设计模式一书中也提到，如果不是一个有经验的面向对象设计人员，建议从最简 单最常用的设计模式入门，比如AbstractFactory模式、Adapater模式、Composite模式、Decorator 模式、Factory 模式、Observer 模式、Strategy 模式、Template 模式等。我的 感触是确实是这样，至少GoF列出的模式我都在开发和设计有用到，如果需要我这里再加上 几个我觉得在开发中会很有用的模式：Singleton模式、Fa9ade模式和Bridge模式。写设计模式解析的目的其实是想把GoF的设计模式进行简化，变得容易理解和接受。GoF的设计模式是圣经，但是同时因为设计模式一书是4位博士的作品，并且主要 是基于Erich的博士论文，博士的特色我觉得最大的就是抽象，将一个具体的问题抽象到一 般，形成理论。因此GoF的这本圣经在很多地方用语都比较精简和抽象，读过的可能都有一 种确实是博士写出来的东西的感觉。抽象的好处是能够提供指导性的意见和建议，其瑕疵就 是不容易为新手所理解和掌握。我的本意是想为抽象描述和具体的实现提供一个桥接（尽管 GoF在书中给出了很多的代码和实例，但是我觉得有两个不足：一是不完整，结果是不好直 接看到演示，因此我给出的代码都是完整的、可编译运行的；二是给出的都是一些比较大的 系统中一部分简单实现，我想GoF的原意可能是想说明这些模式确实很管用，但是却同时带 来一个更大的不好的地方就是不容易为新手理解和掌握），然而这个过程是痛苦的，也可能 是不成功的（可能会是这样）。这里面就有一个取舍的问题，一方面我想尽量去简化GoF 的描述，然而思考后的东西却在很多的时候和GoF的描述很相似，并且觉得将这些内容再抽 象一下，书中的很多表达则是最为经典的。当然这里面也有些许的例外，Bruce Eckel在其 大作Thinking in Patterns）一书中提到：Bridge模式是GoF在描述其23中设计模式中 描述得最为糟糕得模式，于我心有戚戚焉！具体的内容请参看我写的设计模式解析 Bridge模式一文。另外一方面，我又要尽量去避免走到了 GoF一起，因为那样就失去了 我写这个解析的本意了。这两个方面的权衡是很痛苦，并且结果可能也还是没有达到我的本 意要求。第4页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 4月份是我最不忙的时候，也是我非常忙的时候。论文的查阅、思考、撰写，几个项目 的前期准备（文档、Dem。等），俱乐部的诸多事宜，挑战杯的准备，学习（课业、专业等各 个方面）等等，更加重要的是Visual CMCS（Visual C_minus Compiler System）的设 计和开发（Visual CMCS是笔者设计和开发的C_minus语言（C的子集）的编译系统，系统操 作界面类似VC,并且准备代码分发和共享，详细信息请参考Visual CMCS的网站和Blog中的 相关信息的发布），Visual CMCSLO（Beta）终于在4月底发布了，也在别人的帮助下构建 了Visual CMCS的网站（http:）。之所以提及这个，一方面是在Visual CMCS 的设计和开发体验了很多的设计模式，比如Factoty模式、Singleton模式、Strategy模式、State模式等等（我有一篇Blog中有关于这个的不完全的描述）；另外一方面是这个设计模 式解析实际上在这些工作的间隙中完成的，我一般会要求自己每天写一个模式，但是特殊的 时候可能没有写或者一天写了不止一个。写这些文章，本身没有任何功利的杂念，只是一个 原生态的冲动，反而很轻松的完成了。有心栽花未必发，无心之事可成功，世间的事情可能 在很多的时候恰恰就是那样了。最后想用自己在阅读、学习、理解、实现、应用、思考设计模式后的一个感悟结束这个 后记：只有真正理解了设计模式，才知道什么叫面向对象分析和设计。k_eckel写毕于2005-05-04（五四青年节）1：010.3与作者联系AuthorK_EckelStateCandidate for Masters Degree School of Computer Wuhan UniversityE_mailfrwei1创建型模式1.1 Factory 模式问题在面向对象系统设计中经常可以遇到以下的两类问题:第5页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 1）为了提高内聚（Cohesion）和松耦合（Coupling）,我们经常会抽象出一些类的公共 接口以形成抽象基类或者接口。这样我们可以通过声明一个指向基类的指针来指向实际的子 类实现，达到了多态的目的。这里很容易出现的一个问题n多的子类继承自抽象基类，我们 不得不在每次要用到子类的地方就编写诸如new XXX;的代码。这里带来两个问题1）客 户程序员必须知道实际子类的名称（当系统复杂后，命名将是一个很不好处理的问题，为了 处理可能的名字冲突，有的命名可能并不是具有很好的可读性和可记忆性，就姑且不论不同 程序员千奇百怪的个人偏好了。），2）程序的扩展性和维护变得越来越困难。2）还有一种情况就是在父类中并不知道具体要实例化哪一个具体的子类。这里的意思 为：假设我们在类A中要使用到类B,B是一个抽象父类，在A中并不知道具体要实例化 那一个B的子类，但是在类A的子类D中是可以知道的。在A中我们没有办法直接使用类 似于new XXX的语句，因为根本就不知道X X X是什么。以上两个问题也就引出了 Factory模式的两个最重要的功能：1）定义创建对象的接口，封装了对象的创建；2）使得具体化类的工作延迟到了子类中。模式选择我们通常使用Factory模式来解决上面给出的两个问题。在第一个问题中，我们经常就 是声明一个创建对象的接口，并封装了对象的创建过程。Factory这里类似于一个真正意义 上的工厂（生产对象）。在第二个问题中，我们需要提供一个对象创建对象的接口，并在子 类中提供其具体实现（因为只有在子类中可以决定到底实例化哪一个类）。第一中情况的Factory的结构示意图为：第6页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 图1：Factory模式结构示意图1图1所以的Factory模式经常在系统开发中用到，但是这并不是Factory模式的最大威 力所在（因为这可以通过其他方式解决这个问题）。Factory模式不单是提供了创建对象的接 口，其最重要的是延迟了子类的实例化（第二个问题），以下是这种情况的一个Factory的 结构不意图：图2：Factory模式结构示意图1图2中关键中Factory模式的应用并不是只是为了封装对象的创建，而是要把对象的创 建放到子类中实现：Factory中只是提供了对象创建的接口，其实现将放在Factory的子类 ConcreteFactory中进行。这是图2和图1的区别所在。实现完整代码示例（code）Factory模式的实现比较简单，这里为了方便初学者的学习和参考，将给出完整的实现代码（所有代码采用C+实现，并在VC 6.0下测试运行）。代码片断1：Product.h/Product.h#ifndef _PRODUCT_H_#define _PRODUCT_H_class Product（public:virtual Product（）=0;第7页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 protected:Prod u ct();private:)；class ConcreteProduct:publicProduct(public:ConcreteProduct();ConcreteProduct();protected:private:)；#endif 二PRODUCT_H_代码片断 2：Product.cpp/Product.cpp#include Product.h#include using namespace std;Product:Product()()Product:Product()()ConcreteProduct:ConcreteProduct()(cout ConcreteProduct.endl;)ConcreteProduct:ConcreteProduct。第8页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 代码片断3：Factory.h/Factory.h#ifndef _FACTORY_H_#define _FACTORY_H_class Product;class Factory(public:virtual Factory()=0;virtual Product*CreateProduct()=0;protected:Factory();private:)；class ConcreteFactory:public Factory(public:ConcreteFactory();ConcreteFactory();Product*CreateProduct();protected:private:)；#endif/_FACTORY_H_代码片断 4：Factory.cpp/Factory.cpp#include“Factory.第9页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码#include Product.h#include using namespace std;Factory:Factory()()Factory:Factory()()ConcreteFactory:ConcreteFactory()(cout ConcreteFactory.endl;)ConcreteFactory:ConcreteFactory()()Product*ConcreteFactory:CreateProduct()(return new ConcreteProduct();代码片断5：main.cpp/main.cpp#include Factory.h#include Product.h#include using namespace std;int main(int argc,char*argv)(Factory*fac=new ConcreteFactory();Product*p=fac-CreateProduct();return 0;第10页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 代码说明示例代码中给出的是Factory模式解决父类中并不知道具体要实例化哪一个具体的子类 的问题，至于为创建对象提供接口问题，可以由Factory中附加相应的创建操作例如 Create*Product（）即可。具体请参加讨论内容。讨论Factory模式在实际开发中应用非常广泛，面向对象的系统经常面临着对象创建问题：要创建的类实在是太多了。而Factory提供的创建对象的接口封装（第一个功能），以及其 将类的实例化推迟到子类（第二个功能）都部分地解决了实际问题。一个简单的例子就是笔 者开开发VisualCMCS系统的语义分析过程中，由于要为文法中的每个非终结符构造一个类 处理，因此这个过程中对象的创建非常多，采用Factory模式后系统可读性性和维护都变得 elegant 许多。Factory模式也带来至少以下两个问题：1）如果为每一个具体的ConcreteProduct类的实例化提供一个函数体，那么我们可能不 得不在系统中添加了一个方法来处理这个新建的ConcreteProduct,这样Factory的接口永远 就不肯能封闭（Close）。当然我们可以通过创建一个Factory的子类来通过多态实现这一点，但是这也是以新建一个类作为代价的。2）在实现中我们可以通过参数化工厂方法，即给FactoryMethod（）传递一个参数用以 决定是创建具体哪一个具体的Product（实际上笔者在VisualCMCS中也正是这样做的）。当 然也可以通过模板化避免1）中的子类创建子类，其方法就是将具体Product类作为模板参 数，实现起来也很简单。可以看出，Factory模式对于对象的创建给予开发人员提供了很好的实现策略，但是 Factory模式仅仅局限于一类类（就是说Product是一类，有一个共同的基类），如果我们要 为不同类的类提供一个对象创建的接口，那就要用AbstractFactory 了。1.2 AbstactFactory 模式 问题假设我们要开发一款游戏，当然为了吸引更多的人玩，游戏难度不能太大（让大家都没 有信心了，估计游戏也就没有前途了），但是也不能太简单（没有挑战性也不符合玩家的心 第11页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 理）。于是我们就可以采用这样一种处理策略：为游戏设立等级，初级、中级、高级甚至有 BT级。假设也是过关的游戏，每个关卡都有一些怪物（monster）守着，玩家要把这些怪物 干掉才可以过关。作为开发者，我们就不得不创建怪物的类，然后初级怪物、中级怪物等都 继承自怪物类（当然不同种类的则需要另创建类，但是模式相同）。在每个关卡，我们都要 创建怪物的实例，例如初级就创建初级怪物（有很多种类）、中级创建中级怪物等。可以想 象在这个系统中，将会有成千上万的怪物实例要创建，问题是还要保证创建的时候不会出错:初级不能创建BT级的怪物（玩家就郁闷了，玩家一郁闷，游戏也就挂挂了），反之也不可 以。AbstractFactory模式就是用来解决这类问题的：要创建一组相关或者相互依赖的对象。模式选择AbstractFactory模式典型的结构图为：图 2-1：AbstractFactory Pattern 结构图AbstractFactory模式关键就是将这一组对象的创建封装到一个用于创建对象的类（ConcreteFactory）中，维护这样一个创建类总比维护n多相关对象的创建过程要简单的多。实现第12页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 完整代码示例(code)AbstractFactory模式的实现比较简单，这里为了方便初学者的学习和参考，将给出完整 的实现代码(所有代码采用C+实现，并在VC 6.0下测试运行)。代码片断1：Product.h/Product.h#ifndef _PRODUCT_H_#define _PRODUCT_H_class AbstractProductA(public:virtual-AbstractProductA();protected:Abstract ProductA();private:)；class AbstractProductB(public:virtual-AbstractProductB();protected:Abstract ProductB();private:)；class ProductAI:public AbstractProductA(public:ProductAI();ProductAI();protected:private:第13页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码)；class ProductA2:public AbstractProductA(public:Product A2();z ProductA2();protected:private:)；class ProductBI:public AbstractProductB(public:ProductBI();ProductBI();protected:private:)；class ProductB2:public AbstractProductB(public:ProductB2();z ProductB2();protected:private:)；#endif/_PRODUCT_H_代码片断 2：Product.cpp/Product.cpp第14页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码#include Product.h#include using namespace std;AbstractProductA:AbstractProductA()()AbstractProductA:AbstractProductA()()Abstract ProductB:Abstract Prod uctB()()AbstractProductB:AbstractProductB()()ProductAI:ProductAI()(cout ProductAI.endl;)ProductAI:z ProductAI()()ProductA2:ProductA2()(cout ProductA2.endl;)ProductA2:ProductA2()()ProductBI:ProductBI()第15页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 cout ProductBI.endl;)ProductBI:z ProductBI()()ProductB2:ProductB2()(cout ProductB2”v endl;)ProductB2:ProductB2()(_代码片断 3：Ab str actF actory.h/Abstract Factory.h#ifndef _ABSTRACTFACTORY_H_#define _ABSTRACTFACTORY_H_class AbstractProductA;class AbstractProductB;class Abstract Factory(public:virtual-AbstractFactory();virtual AbstractProductA*CreateProductA()=0;virtual AbstractProductB*CreateProductB()=0;protected:Abstract Factory();private:)；class ConcreteFactoryl:public Abstract Factory(public:第16页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 ConcreteFactoryl();ConcreteFactoryl();AbstractProductA*CreateProductA();AbstractProductB*CreateProductB();protected:private:)；class ConcreteFactory2:public Abstract Factory(public:ConcreteFactory2();ConcreteFactory2();AbstractProductA*CreateProductA();AbstractProductB*CreateProductB();protected:private:)；#endif/_ABSTRACTFACTORY_H_代码片断 4：Ab stractFactory.cpp/Abstract Factory.cpp#include AbstractFactory.h#include Product.h#include using namespace std;AbstractFactory:AbstractFactory()()Abstract Factory:AbstractFactory。第17页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码)ConcreteFactory 1:ConcreteFactory1()()ConcreteFactoryl:ConcreteFactoryl()()AbstractProductA*ConcreteFactoryl:CreateProductA()(return new ProductAI();)AbstractProductB*ConcreteFactoryl:CreateProductB()(return new ProductBI();)ConcreteFactory2:ConcreteFactory2()()ConcreteFactory2:ConcreteFactory2()()AbstractProductA*ConcreteFactory2:CreateProductA()(return new ProductA2();)AbstractProductB*ConcreteFactory2:CreateProductB()(return new ProductB2();代码片断5：main.cpp/main.cpp第18页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码#include AbstractFactory.h#include using namespace std;int main(int argc.char*argv)(Abstract Factory*cf1=new ConcreteFactoryl();cf1-CreateProductA();cf1-CreateProductB();Abstract Factory*cf2=new ConcreteFactory2();cf2-CreateProductA();cf2-CreateProductB();return 0;J_代码说明AbstractFactory模式的实现代码很简单，在测试程序中可以看到，当我们要创建一组对 象(ProductAI,ProductA2)的时候我们只用维护一个创建对象(ConcreteFactoryl),大大 简化了维护的成本和工作。讨论AbstractFactory模式和Factory模式的区别是初学(使用)设计模式时候的一个容易弓I 起困惑的地方。实际上，AbstractFactory模式是为创建一组(有多类)相关或依赖的对象提 供创建接口，而Factory模式正如我在相应的文档中分析的是为一类对象提供创建接口或延 迟对象的创建到子类中实现。并且可以看到，AbstractFactory模式通常都是使用Factory模 式实现(ConcreteFactory 1)。1.3 Singleton 模式 问题个人认为Singleton模式是设计模式中最为简单、最为常见、最容易实现，也是最应该 熟悉和掌握的模式。且不说公司企业在招聘的时候为了考察员工对设计的了解和把握，考的 最多的就是Singleton模式。Singleton模式解决问题十分常见，我们怎样去创建一个唯一的变量(对象)？在基于 第19页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 对象的设计中我们可以通过创建一个全局变量（对象）来实现，在面向对象和面向过程结合 的设计范式（如C+中）中，我们也还是可以通过一个全局变量实现这一点。但是当我们遇 到了纯粹的面向对象范式中，这一点可能就只能是通过Singleton模式来实现了，可能这也 正是很多公司在招聘Java开发人员时候经常考察Singleton模式的缘故吧。Singleton模式在开发中非常有用，具体使用在讨论给出。模式选择Singleton模式典型的结构图为：I Singleton PatternSingletoninstance+lnstance（）I _7图 2-1：Singleton Pattern 结构图在Singleton模式的结构图中可以看到，我们通过维护一个static的成员变量来记录这 个唯一的对象实例。通过提供一个staitc的接口 instance来获得这个唯一的实例。实现 完整代码示例（code）Singleton模式的实很简单，这里为了方便初学者的学习和参考，将给出完整的实现代 码（所有代码采用C+实现，并在VC 6.0下测试运行）。代码片断 1：Singleton.h/Singleton.h#ifndef _SI NGLETON_H_#define _SINGLETON_H_#include using namespace std;class Singleton（public:static Singleton*Instance（）;protected:第20页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 Singleton();private:static Singleton*_instance;)；#endif _SINGLETON_H_代码片断 2：Singleton.cpp/Singleton.cpp#include Singleton.h#include using namespace std;Singleton*Singleton:_instance=0;Singleton:Singleton()(cout Singleton.endl;)Singleton*Singleton:Instance()(if(_instance=0)(_instance=new Singleton();)return _instance;代码片断3：main.cp/main.cpp#include Singleton.h#include using namespace std;int main(int argc,char*argv)(Singleton*sgn=Singleton:lnstance();第21页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 return 0;J_代码说明Singleton模式的实现无须补充解释，需要说明的是，Singleton不可以被实例化，因此 我们将其构造函数声明为protected或者直接声明为private0讨论Singleton模式在开发中经常用到，且不说我们开发过程中一些变量必须是唯一的，比 如说打印机的实例等等。Singleton模式经常和Factory（AbstractFactory）模式在一起使用，因为系统中工厂对象 一般来说只要一个，笔者在开发Visual CMCS的时候，语义分析过程（以及其他过程）中 都用到工厂模式来创建对象（对象实在是太多了），这里的工厂对象实现就是同时是一个 Singleton模式的实例，因为系统我们就只要一个工厂来创建对象就可以了。1.4 Builder 模式 问题生活中有着很多的Builder的例子，个人觉得大学生活就是一个Builder模式的最好体验:要完成大学教育，一般将大学教育过程分成4个学期进行，因此没有学习可以看作是构建完 整大学教育的一个部分构建过程，每个人经过这4年的（4个阶段）构建过程得到的最后的 结果不一样，因为可能在四个阶段的构建中引入了很多的参数（每个人的机会和际遇不完全 相同）。Builder模式要解决的也正是这样的问题：当我们要创建的对象很复杂的时候（通常是 由很多其他的对象组合而成），我们要要复杂对象的创建过程和这个对象的表示（展示）分 离开来，这样做的好处就是通过一步步的进行复杂对象的构建，由于在每一步的构造过程中 可以弓I入参数，使得经过相同的步骤创建最后得到的对象的展示不一样。模式选择Builder模式的典型结构图为：第22页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 图 2-1：Builder Pattern 结构图Builder模式的关键是其中的Director对象并不直接返回对象，而是通过一步步（BuildPartA,BuildPartB,BuildPartC）来一步步进行对象的创建。当然这里Director可以 提供一个默认的返回对象的接口（即返回通用的复杂对象的创建，即不指定或者特定唯一指 定BuildPart中的参数）。实现 完整代码示例（code）Builder模式的实现很简单，这里为了方便初学者的学习和参考，将给出完整的实现代码（所有代码采用C+实现，并在VC 6.0下测试运行）。代码片断1：Product.h/Product.h#ifndef _PRODUCT_H_#define _PRODUCT_H_class Product（public:Product（）;第23页共171页k eckel设计模式精解一GoF 23种设计模式解析附C+实现源码 Product();void ProducePart();protected:private:)；class Product Part(