适配器模式：     又称变压器模式，它是把一个类的接口转换为客户端所期望了另一种接口，从而使原本因为接口不匹配而无法一起工作的两个类能一起工作。      适用：     希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。增强代码的可维护性。      方法：     1.对象适配器：采用“对象组合”，耦合度低，推荐使用。     2.类适配器：多采用多继承，会使程序高

前言：    这个国庆，回家不想学习，于是下了个三国志11，玩了好几天，终于从一个只有一个城池，5、6个武将，一两万士兵的刘备，发展成占有半壁江山了，灭了曹操，袁绍等，那在玩游戏的时候，我肯定不能连续几十个小时都不退出游戏，或者说不关机，那我每次肯定都需要保存游戏进度才能下次继续玩，那这就用上我这次要说的备忘录模式了，每次讲记录保存在存档里，下次进入游戏又可以接着上一次继续玩了~

在GOF的《设计模式:可复用面向对象软件的基础》一书中对策略模式是这样说的：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。该模式使得算法可独立于使用它的客户而变化。 组成： （1）Strategy—抽象策略角色： 策略类，通常由一个接口或者抽象类实现。 {      定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，Context使用这个接口调用不同的算法，一

前言     在平常生活当中，我们经常要使用到迭代器，例如在观看一组图片时，我们经常使用遍历的方法观看，我们并不需要具体研究图片的结构，只需要遍历，并且可以将当前的遍历状态记录下来，下次观看时可以从之前的遍历终止点开始继续。     即在面向对象的软件设计中，我们经常会遇到一类集合对象，这类集合对象的内部结构可能有着各种各样的实现，但是最重要的是有两点是需要我们去关心的：一是集合内部的数据存储

工厂模式分为： 1、简单工厂模式 2、

虚函数特殊的一个情况就是基类和子类的返回类型可以分别是它们自身的类型! #include using namespace std; //接口 class Product { public: Product(){} virtual ~Product(){} virtual void fun() { cout } virtual Product *

单例模式可能是使用最广泛的设计模式。其意图是保证一个类仅有一个实例，并提供一个访问它的全局访问点，该实例被所有程序模块共享。有很多地方需要这样的功能模块，如系统的日志输出，还有最近项目中用到的scoket通信，只能

观察者模式（Observer）完美的将观察者和被观察的对象分离开。        在GOF的《设计模式:可复用面向对象软件的基础》一书中对观察者模式是这样说的：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。当一个对象发生了变化，关注它的对象就会得到通知；这种交互也称为发布-订阅(publish-subscribe)。目标是通知的发

一个复杂对象的创建，其通常是由很多的子对象构成；如果一个对象能够直接就创建好了，那么也不会称之为复杂对象。由于项目中需求的变化，这个复杂对象的各个部分经常会发生剧烈的变化，但是，不管怎么变化，将它们组合在一起，组成一个复杂的对象的事实是不会变的。建造者模式就提供了一种“封装机制”来将各个对象的变化隔离开，最终，组合成复杂对象的过程是不会变的。 在《大话设计模式》一书中，例举了一个很好的例子—

一、享元模式 享元模式（英语：Flyweight Pattern）是一种软件设计模式。运用共享技术有效的支持大量细粒度的对象。它使用共享物件，用来尽可能减少内存使用量以及分享资讯给尽可能多的相似物件；它适合用于只是因重复而导致使用无法令人接受的大量内存的大量物件。通常物件中的部分状态是可以分享。常见做法是把它们放在外部数据结构，当需要使用时再将它们传递给享元。 二、何时使用： 1.一

概述 ：   在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？        问题就是如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。 意图: 　　　将抽象部分与实现部分分离，使它们都可以独立的变化。

一、前言 平常我们写一个聊天软件，如果我们只是各个客户端之间连接聊天，那估计我们会写的想哭，那如果我们用服务器作为中间媒介，通过服务器来完成转发，群聊等客户端之间的连接，那样我们就可以最大程度的为各个客户端之间解耦，把它们之间的通信方法抽出来单独实现， 如图1就是不使用中介媒体的时候的结构图： 如图2就是使用我们所说的服务器作为中间媒介的情况的结构图： 二、中介模式