C++设计模式（自己根据博客整理的）.pdf-资料库

qq_20717745-9599999-4744300845224291386.pdf-第1页.png

第1页 / 共182页

qq_20717745-9599999-4744300845224291386.pdf-第2页.png

第2页 / 共182页

qq_20717745-9599999-4744300845224291386.pdf-第3页.png

第3页 / 共182页

qq_20717745-9599999-4744300845224291386.pdf-第4页.png

第4页 / 共182页

qq_20717745-9599999-4744300845224291386.pdf-第5页.png

第5页 / 共182页

qq_20717745-9599999-4744300845224291386.pdf-第6页.png

第6页 / 共182页

qq_20717745-9599999-4744300845224291386.pdf-第7页.png

第7页 / 共182页

qq_20717745-9599999-4744300845224291386.pdf-第8页.png

第8页 / 共182页

uml 类图常见关系来源：互联网作者：佚名时间：04-29 15:48:42 【大中小】本篇讲解在 UML 类图中，常见的几种关系: 泛化（Generalization），依赖(Dependency)，关联（Association)，聚合（Aggregation），组合(Composition),需要的朋友可以参考下 1.泛化关系泛化关系是继承或实现的关系，是 is-a 关系，具体表现为类与类的继承，接口与接口的继承，类对接口的实现关系。 2.依赖关系依赖关系表示为一个类使用另一个类，这种使用关系是具有偶然性的、临时性的、非常弱的，一个类的变化会影响到另一个类，是 use a 关系，如果类 A 依赖于类 B,那么类 B 可以是类 A 的局部变量，或类 A 方法的参数，或静态方法的调用。

3.关联关系关联关系是一种强依赖关系，这种关系不存在依赖关系的偶然性，关系也不是临时的，是长期的，稳定的。双方的关系是平等的，可以单向关联也可以是双向关联。假如类 A 关联了类 B,则类 B 是类 A 的全局变量（注意是全局变量，再看看上面的依赖关系），大多数关联都是单向关联，这比较容易维护，关于关联，在生活中我们常会说，类 A 持有类 B 的引用。 4.聚合关系聚合关系是特殊的关联关系，是一种强的关联关系，他体现的是整体与部分关系，即 has-a 的关系，但是整体和部分是可以分离的，注意，是可以分离的。普通关联关系的两个类处于同一层次上，是平级的，而聚合关系的两个类处于不同的层次，一个是整体，一个是部分。

同时，是一种弱的“拥有”关系。体现的是 A 对象可以包含 B 对象，但 B 对象不是 A 对象的组成部分。具体表现为，如果 A 由 B 聚合成，表现为 A 包含有 B 的全局对象，但是 B 对象可以不在 A 创建的时刻创建，这句话非常有意义，它在代码中通常体现成依赖注入的 sette r 方法，即 A 对象可以随时创建 B 对象，再想想这不就体现了整体和部分是可以分离了吗？创建整体的时候可以不创建部分。 5.组合关系组合关系也是特殊的关联关系，它体现一种 contains a（拥有）关系，这种关系是比聚合还要强，也称为强聚合。体现了严格的整体和部分关系，两者是不可分割的，它们的生命周期是一致的。如果 A 由 B 组成，那么 A 就包含 B 的全局变量，并在创建 A 的同时创建 B，在代码上我们通常是使用构造函数进行实现，也是依赖注入中构造函数的实现。

最后，我们来总结一下，泛化就不用多少了，大家都懂的，就是继承和实现接口，重点说下其它的吧，依赖，ClassB 体现为 ClassA 的局部变量，我想用就用，用了就有关系，不用就没关系；关联，ClassB 体现为 ClassA 的全局变量，不管你用不用，反正你知道我的存在了，持有了我的引用。聚合，是特殊的关联关系，用了就加强了关系，不用还是我只知道你的存在。聚合可以方便的持有多个类的引用，如使用 List<>，所以当你发现有 List<>等集合是可以使用聚合来表示，比如观察者模式的结构。组合，体现最强的关系，比如人出身了，必定也有头部吧，不然我真无法想象这个世界了。 C++设计模式之工厂方法模式作者：果冻想字体：[增加减小] 类型：转载时间：2014-09-30 这篇文章主要介绍了 C++设计模式之工厂方法模式,它是对简单工厂模式的扩展,,需要的朋友可以参考下问题描述之前讲到了 C++设计模式——简单工厂模式，由于简单工厂模式的局限性，比如：工厂现在能生产 ProductA、ProductB 和 ProductC 三种产品了，此时，需要增加生产 ProductD 产品；那么，首先是不是需要在产品枚举类型中添加新的产品类型标识，然后，修改 Factory 类中的 switch 结构代码。是的，这种对代码的修改，对原有代码的改动量较大，易产生编码上的错误（虽然很简单，如果工程大了，出错也是在所难免的！！！）。这种对代码的修改是最原始，最野蛮的修改，本质上不能称之为对代码的扩展。同时，由于对已经存在的函

数进行了修改，那么以前进行过的测试，都将是无效的，所有的测试，都将需要重新进行，所有的代码都需要进行重新覆盖。这种，增加成本，不能提高效率的事情，在公司是绝对不允许的（除非昏庸的 PM）。出于种种原因，简单工厂模式，在实际项目中使用的较少。那么该怎么办？怎么办呢？需要对原有代码影响降到最小，同时能对原有功能进行扩展。 UML 类图那么今天介绍的工厂方法模式，就隆重登场了。它只是对简单工厂模式的扩展，在 GOF 的介绍中，它们是合并在一起的，而我则是单独分开进行讲解的，就是为了区分二者的利弊，便于大家在实际项目中进行更好的把握与应用。工厂方法模式是在简单工厂模式的基础上，对“工厂”添加了一个抽象层。将工厂共同的动作抽象出来，作为抽象类，而具体的行为由子类本身去实现，让子类去决定生产什么样的产品。如图，FactoryA 专心负责生产 ProductA，FactoryB 专心负责生产 ProductB，FactoryA 和 F actoryB 之间没有关系；如果到了后期，如果需要生产 ProductC 时，我们则可以创建一个 F actoryC 工厂类，该类专心负责生产 ProductC 类产品。由于 FactoryA、FactoryB 和 Factory C 之间没有关系，当加入 FactoryC 加入时，对 FactoryA 和 FactoryB 的工作没有产生任何影响，那么对代码进行测试时，只需要单独对 FactoryC 和 ProductC 进行单元测试，而 Factor yA 和 FactoryB 则不用进行测试，则可省去大量无趣无味的测试工作。适用场合工厂方法模式的意义是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。 1.在设计的初期，就考虑到产品在后期会进行扩展的情况下，可以使用工厂方法模式； 2.产品结构较复杂的情况下，可以使用工厂方法模式；由于使用设计模式是在详细设计时，就需要进行定夺的，所以，需要权衡多方面的因素，而不能为了使用设计模式而使用设计模式。

代码实现: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 /* ** FileName ** Author ** Date ** Description : More information, please go to http://www.jb51.net */ : FactoryMethodPatternDemo : Jelly Young : 2013/11/18 #include using namespace std; class Product { public: virtual void Show() = 0; }; class ProductA : public Product { public: void Show() { cout<< "I'm ProductA"<

42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 { public: Product *CreateProduct() { return new ProductA (); } }; class FactoryB : public Factory { public: Product *CreateProduct() { return new ProductB (); } }; int main(int argc , char *argv []) { Factory *factoryA = new FactoryA (); Product *productA = factoryA->CreateProduct(); productA->Show(); Factory *factoryB = new FactoryB (); Product *productB = factoryB->CreateProduct(); productB->Show(); if (factoryA != NULL) { delete factoryA; factoryA = NULL; } if (productA != NULL) { delete productA; productA = NULL; } if (factoryB != NULL) { delete factoryB; factoryB = NULL;

85 86 87 88 89 90 91 92 93 } if (productB != NULL) { delete productB; productB = NULL; } return 0; } C++设计模式之适配器模式作者：果冻想字体：[增加减小] 类型：转载时间：2014-09-30 这篇文章主要介绍了 C++设计模式之适配器模式,本文详细讲解了 C++中的适配器模式,并给出了实现代码,需要的朋友可以参考下生活中的适配器买笔记本电脑，买手机时，都有一个电源适配器，电源适配器又叫外置电源，是小型便携式电子设备及电子电器的供电电压变换设备，常见于手机，笔记本电脑上。它的作用是将家里的 220V 高电压转换成这些电子产品能工作的 5V~20V 左右稳定的低电压，使它们能正常工作。就是说，如果没有这个电源适配器，我们的手机和电脑就不能进行充电了。之前同事去日本出差，由于工作需要，就将自己的笔记本带过去了。到了的当晚就悲剧了，笔记本无法使用。由于日本的居民用电电压是 110V，而中国是 220V，同事的笔记本是 22 0V 供电的。第二天，同事就去买了一个电压适配器。如果没有电压适配器，估计这次出差都要悲剧了。什么是适配器模式？说了这么多生活中的适配器的例子，那么在软件设计、开发过程中，适配器又是个什么东西呢？在 GOF 的《设计模式：可复用面向对象软件的基础》中是这样说的：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。好比日本现在就只提供 110V 的电压，而我的电脑就需要 220V 的电压，那怎么办啦？适配器就是干这活的，在不兼容的东西之间搭建一座桥梁，让二者能很好的兼容在一起工作。为什么要使用适配器模式？在软件开发中，有的时候系统的数据和行为都正确，但接口不符合，我们应该考虑使用适配器模式，目的是使控制范围之外的一个原有对象与某个接口匹配。举个例子：在开发一个模块的时候，有一个功能点实现起来比较费劲，但是，之前有一个项目的模块实现了一样的功

资料库

C++设计模式（自己根据博客整理的）.pdf

相关推荐

开发技术

热门标签

最新资料