俊哥有个Blog

如果你研究过visitor pattern，很可能会涉及到一个Double Dispatch的概念，这里我们就叫它双重分发吧，双重分发是一种思想，而访问者模式则是一种具体实现。本文会尽量以一种通俗的语言来描述这些概念（本文以C++为例）。首先我们梳理一下比较熟悉的两个基本概念：静态类型(static type)与动态类型(dynamic type)。静态类型是在编译期需要确定并进行检查的，检查...

迭代器我们都用过，不管是C++，PHP等等，它们是标准库给我们实现好的，通过它能访问像vector, list这样的容器。如果我们自己有一个对象集合，你也想提供这样的接口，那就要自己实现。迭代器模式：使用迭代器模式来提供对聚合对象的统一存取，即提供一个外部的迭代器来对聚合对象进行访问和遍历 , 而又不需暴露该对象的内部结构。如果不用该模式，你可以在聚合对象中添加遍历的函数，这增加了聚合对象

中介者模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。这个定义说白了，两个对象要交互（或者说通信，随便怎么说吧），直接组合对方的类指针的话耦合性太高。中间用一个类包装一下，这样，相互通信的类里面直接通过这个包装类操作就行了！说实在的，我没有实际用过这个模式，也没体会过它的好处，我就通过总结网上别人的帖子来写一下。

桥接模式的原理是：将抽象部分与实现部分分离，使他们可以独立地变化！ 这里的实现不是指具体子类对抽象基类中的虚函数的实现，而是指用户需求变化的具体实现操作！比如有多种型号的计算机和多种操作系统，假设他们的装机方式各不相同，其UML图(来自网络)如下：抽象与实现之间不用继承，而是通过组合的方式实现的！如果用继承，你想，3种电脑*3种OS，得有9个继承子类来实现装系统的方法！像这种有笛卡尔积

这个模式讲真我理解不是很清楚，它的应用也是非常非常少，因为没用过，也不清楚它的应用场景。为了完结这一系列文章，还是把它写一写！解释器嘛，对一个文法或表达式进行解释，好比编译系统对编程语言的解释，计算系统对计算模型的解释。举个列子，公司要对大数据进行处理，根据不同的需求，会建立很多不同的模型，a+b-c; a+b+c-e; a-b 等等。有人可能会想，我直接写计算表达式呗，有一个模型就写一个表达

命令模式

访问者模式

这个模式我觉得是很简单的--单例模式还有很多陷阱呢，职责链模式在你了解了使用场景以及它的实现之后，一切都是顺理成章的事。请假--大家都举这个例子，3天以内组长批，3-7天部门经理批，7天以上总经理批。请假的人只管把假条交上就行了，批假的处理不用管，这就实现了请求和处理的解耦(这话怎么好多模式都这么说)。在实现上就是，要在处理类中组合一个上一级的对象指针就行了，自己处理不了交给它处理。该模式的好

外观模式

策略模式，它解决的问题与前一篇Template模式类似，都是为了给逻辑(算法)具体实现和抽象接口之间的解耦。策略模式将将接口的实现放在被组合对象中，将抽象接口放在组合类中。策略模式使得算法可以在不影响到客户端的情况下进行替换。以缓冲区替换算法为例，UML图如下：有几点：1. 在Cache类中组合了一个ReplaceAlgorithm *类型的指针。这时候在Client中使用时，需要

单例模式在系统开发时很常见，一个系统中可能会有多个单例模式的运用！它比全局变量的好处？1.能控制生成时间，保证初始化顺序？2. 容易保证线程安全(全局变量需要多线程client单独控制并发，单例在类实现中已经做到，无需client再处理)？3. 减少函数模块之间的耦合，减少命名冲突，便于管理？ 可能这些都是好处吧！我的项目开发过程中，经常会把单例模式和简单工厂模式结合起来使用！比如：cla

备忘录模式

观察者模式，项目中用的很多，因为它的逻辑比较清晰，实现方法比较统一，所以也挺好理解的！观察者模式：定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。这句话中对象间就是某个被观察的东西Subject和观察者Observer，一个Subject可以有一个或多个Observer(下图只画了一个)；状态改变，也就是Subject的状态改变时(通过

状态模式：事物在不同状态下会有不同表现（动作），经过不同动作后，又会转移到下一个不同的状态。这种问题可以用Switch/Case（if-else）搞定， 但如果case语句很多，就很麻烦，这种实现也没有将逻辑和动作分离，后期维护得不到保证！加case语句要修改原来代码，违反了“对扩展开放，对修改关闭”的原则！State 模式将每一个case分支都封装到独立的类中！状态模式的具体实现类中有一

一， 简单工厂模式主要特点是需要在工厂类中用多个case分支做判断，根据传递进来的参数创造相应的产品。当增加新的产品时，当然也得修改工厂类，就是在其中添加case分支。在平时开发的小项目里，由于对象类型单一、个数基本确定，所以基本采用这种方法来实现！并且它会和单例模式放在一起，比如我项目中就采用下面的方法：class OPTSOLVER_API CGasElementFactory{

Prototype模式-原形模式，就是自我复制，一个clone函数的事。先把UML图贴出来。不同的语言实现可能不同，在C++中，一般clone的实现是：Prototype* ConcretPrototype::Clone() const{ return new ConcretPrototype(*this);}这一句很简单，但是它依赖于复制构造函数中对深拷贝和浅拷贝的完

首先贴出一篇不错的关于builder模式的博文：点击打开链接 文中举的第一个反例的博文在这里：点击打开链接修改后的UML图如下：整个图反映了作者的思想，重点就在Director中的CreateEQP中，也就是说把由Builder继承来生成子类的方法，改在CreateEQP中进行。我个人特别不理解的是：builder子类相当于一个创建某类东西的模板，按作者的意思，不能因为某个特点不同

适配器模式，顾名思义，适配两个不同的东西！实事上，它的用处更多的确实是用在：当前项目开发，用到第三方的库，我们自己的项目接口已经设计好，但它与第三方库的接口不一致，为了这些接口不兼容的类能一起工作，就需要用到Adapter模式将第三方库的接口转化为用户希望的接口形式！说通俗一点：我们的类A

装饰模式，通过组合而不是继承的方式，动态地给类增加功能的方法！这句话不好理解，边看下图例子边说话吧：Streams是大多数I / O设备的基础抽象结构，它提供了将对象转换成为字节或字符流的操作接口，使我们可以将一个对象转变成一个文件或内存中的字符串。一个简单直接的方法是定义一个抽象的Stream类，它有两个子类MemoryStream与FileStream。但假定我们还希望能够做下面一些事情（添加

组合模式，UML图和装饰模式非常像，但二者代表的意义是不同的. 装饰主要用来在已有的类中添加功能; 组合模式主要是：在开发中会遇到一些树形组织结构的现实对象，比如：电脑主板，包括：CPU，芯片组，I/O设备等；其中的芯片组包括：声卡芯片，显卡芯片；I/O设备包括：USB I/O,  VGA I/O等。这里的cpu， 声卡芯片等可以看作是叶节点。芯片组、I/O设备可看作是组合元件。再比如，一个大公司

享元模式。Flywight是轻量级的意思，翻译成享元算是意译吧！其定义为：运用共享技术有效地支持大量细粒度的对象！举个例子，文档编辑器程序中如果一个字符对应一个对象，那一篇文档所有字符对象将非常的耗费内存。实际上，所有字符的个数是有限的，只是有些地方字符的一些属性：颜色、大小等不太一样！因此，可以将有限的字符对象构建后共享出来，这些是他们的内部状态，存储在flywight中；其它如颜色、大小等属性

代理模式，顾名思义，代替某个东西去完成某事！GOF书上分为四类：远程（Remote）代理：为一个位于不同的地址空间的对象提供一个局域代表对象。比如：你可以将一个在世界某个角落一台机器通过代理假象成你局域网中的一部分。虚拟（Virtual）代理：根据需要将一个资源消耗很大或者比较复杂的对象延迟的真正需要时才创建。比如：如果一个很大的图片，需要花费很长时间才能显示出来，那么当这个图片包含在

模板模式，逻辑很清晰，容易实现，用的也多！需求情景就是：对一个业务逻辑/算法实现，在不同对象中有不同的细节实现，但是逻辑的框架是相同的！就是说它们的操作步骤/接口是相同的，以继承的方式实现！看下图UML就明白了：到公司应聘，公司给每人发一个简历表，让大家填，而不是直接用每个人自己带的简历！有几点：1. 将逻辑框架放在抽象基类中，并定义好细节的接口，子类中实现细节！ 这和Strategy