zj510的专栏

从这个文章开始，我们讲结构型模式。结构型模式涉及到如何组合类和对象以获得更大的结构。先从适配器模式(Adapter)开始。现实生活中，适配器的情况还是挺多的。比如我去年买了个台湾版HTC手机，但是在杭州用不了，因为这个手机的充电器的插头跟插座不匹配，然后我去电脑市场花了5快钱买了个转接头，现在就可以用了。其实这也是一个适配器的例子。这里面，现有的插座就是Adeptee，转接头就是Adapt

Mediator pattern， 中介模式。中介模式还是蛮有用的。OOP程序设计鼓励我们把行为分布到各个对象中，但是这样可能会导致有大量的对象，并且这些对象之间会有很多连接，或者称之为耦合。而且这些耦合是错中复杂的。比如有A,B,C,D四个类，A和B耦合，B和C耦合，D和A耦合，等等。最坏的情况就是A必须知道B,C,D三个类。这样就搞的整个系统变成一个不可分割的整体，任何修改的代价都很高，比如修

观察者模式，也有叫发布-订阅模式的。这是个人比较喜欢的设计模式之一。因为它比较容易使用，而且效果还挺好。意图定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。结构其实，观察者模式里面目标对象和观察者对象还是松耦合的。目标对象需要知道观察者的一些比较固定的接口，比如Update()，同时观察者也需要知道目标对象的一些状态，因为

State Pattern，状态模式。个人用的蛮多的一种模式。意图允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。结构结构图还是蛮简单的，主要涉及两个类，context和state。state类会处理一些行为。状态模式的一个重要的特征就是：把和状态相关的行为都放入一个对象中。因为所有和状态相关的代码都存在于某一个state子类中，所以通过定义新的子类可以

Strategy Pattern，个人用的最多的一种模式之一。这种模式比较简单，但是却很有效。意图定义一系列的算法，把它们一个一个封装起来，并且使它们可以互相替换。本模式使得算法可独立于使用它的客户而变化。结构从结构上看策略模式还是蛮简单的，两个参与者：context和strategy。context会将它的客户的请求转发给context的策略对象。从而相应的策略对象可以完成客

模板方法模式，很多人可能并不知道这么个模式，但是实际上已经在使用了。我们经常会碰到这么一种情况：在不同的子类里面发现有些代码是一样的。那么自然就会把这些代码放到它们的基类里面去。子类只实现不同的部分。这其实就已经在使用模板方法模式了。意图定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的结构即可重定义算法的某些特定步骤。结构图

访问者模式（Visitor Pattern），据说是一种相对复杂，而且使用条件苛刻的模式。但是Gof既然把它归到23种设计模式里面，那总有它存在的道理。在职责链模式里面，有个领导审批的例子，http://blog.youkuaiyun.com/zj510/article/details/8156852。CLeader类有审批接口，如：class CLeader{public: CLeader(C

行为型模式总共有11种：职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式和访问者模式。 封装变化封装变化是很多行为模式的主题。当一个系统里面某些特性经常发生变化的时候，我们常常可以使用一个相应的行为模式来封装。所以，行为型模式里面很多模式都会具有两种对象：1. 封装特征的对象；2. 使用这些特征的对象。如果不

回调函数，相信很多人都用过。比如A中定义一个函数，然后A把这个函数指针发给B，B在某个时刻调用这个指针。这就是个回调。其实在过去面向过程语言，比如C语言里面是大量的用到回调函数。就算是现在面向对象的语言，比如JAVA,C#, 有时也还是会用到回调函数。考虑这么一个例子，有一个加密软件，支持MD5加密和RSA加密。在这个软件的UI界面上有两种方式使用加密：菜单和一个按钮。通过菜单可以对一个文件加

Abstract Server是一个很简单的模式，很多时候大家都在用，只是没有去总结。Uncle Bob提出了这个概念（见Agile Software Development）。Abstract Server相关的一些概念还是很重要的，也很有启发。通常，Abstract Server就直接体现了DIP(依赖倒置）。DIP是一个很重要的概念。往往遵守DIP原则的代码灵活性会更好。

singleton，单例模式，这是非常常用的一种模式，相信大多数人都知道。

ActiveObject模式，很古老，但是在某些场合又很有威力。可以用一个单线程来控制多任务。通常配合Command模式使用。

NULL Object，这是个很简单又很有趣的模式。

大多数人说的工厂模式，应该是指GOF设计模式里面的Abstract Factory模式。这是一种hen

传统访问者模式 VS 无环访问者模式 （ACyclic Visitor）

http://www.open-open.com/lib/view/open1328059700311.html

Memento pattern，备忘录模式。不知道哪位老兄第一个翻译的，翻译的真形象。备忘录，就是将某个对象的某个时刻的状态保存下来，以后可以继续查看，还可以恢复状态。意图在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。结构从这个结构图可以看到，Originator会创建一个备忘录，然而这个备忘录不是保存在O

从来没用过，不解。以后有机会再讲。

全部五种创建型模式已经介绍完毕了：工厂方法模式，抽象工厂模式，生成器模式，原型模式和单例模式。我始终认为设计模式是一些牛人总结出来的一些经验，我们不必死搬硬套。但是这些设计模式已经这么多年了，经受住了大量的考验。而且大多数人认为是合理的。那么就值得我们借鉴。我本人的日常工作中也大量的用到了这些设计模式。对于创建型模式来说，我用的比较多的是工厂方法模式，生成器模式和单例模式。我个人觉得还

桥接模式是结构型模式里面相对复杂的一种模式，但是同时也是很有用的。我们先来考虑这么一种情况（这个例子是设计模式书上的一个例子），Window是一个类，这个类用来画一个窗口。那么我们现在如果要支持XP风格和WIN7风格，应该怎么做呢？通常首先能想到的就是子类化Window，比如增加2个类：WindowsXP和Windows7。然后这2个子类可以各自实现各自的风格，这个没有问题。而且这也是常用办法

上次我讲了一下工厂方法模式，这次我来讲一下抽象工厂模式。其实，我在工作当中基本没有用到过抽象工厂模式。我用的比较多的是工厂方法模式。我对抽象工厂模式的理解主要来自《设计模式》这本书。同时也搜索了一些网上的文章。这里我就讲一下我自己的理解，如果讲的不好，或者根本就讲错了，请大家谅解。 抽象工厂模式 （Abstract Factory）意图提供一个创建一系列相关或相互依赖对象的

讲完了适配器和桥接模式，我们这次来看看组合模式（Composite）。 意图将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。 结构图从上面的结构图可以看出，Composite聚合了Component，那么也就是说Composite里面可以保存任何Component的子类，比如一个Leaf或者另外一个Co

小弟我最近重新学习设计模式。经典就是经典，这本书我已经看了至少两遍了，这次重新再看一次，发现又体会到不同的东西了。身边很多朋友都在写博客，那么我也凑凑热闹，一来可以加深自己的学习，二来也可以给朋友们参考参考。限于本人能力有限，如果写的不好的地方请多多包涵，如果有什么理解错误的地方，欢迎指出。好了，废话少说，切入正题。先从创建型模式开始吧。我最熟悉的语言是C++,所以所有的例子都

这次我们来讲一下原型模式。总体来讲原型模式还是比较简单的。 意图用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 结构图这个结构图还是挺简单的，Prototype就是产品类。和前面的抽象工厂，工厂方法等模式相比，产品类就增加了一个函数Clone()。我们还是以之前的地形例子来讲解这个模式，先给出类图我这次把CFactory当作原型模式的c

创建型模式的最后一个内容是单例模式（singleton）我相信很多人对单例模式都很熟悉，因为这个模式非常普遍。这里我也简单介绍一下。 意图保证一个类仅有一个实例，并提供一个访问它的全局访问点。 结构图单例模式的关键在于2点：1. 构造函数是私有的，也就是说除了这个单例类本身其他人是不可以创建单例类对象的；2. 有一个公有的静态函数（上图中的GetInst()

前两个文章我介绍了工厂方法模式和抽象工厂模式，这次我来讲一些生成器模式。生成器模式我也用的比较多。5个创建型模式里面，我比较喜欢用工厂方法模式，生成器模式和单例模式。 意图将一个复杂对象的构建与它的表示分开，使得同样的构建过程可以创建不同的表示。 结构图  一眼看去是不是和抽象工厂模式有点像？是啊，我也觉得很像，有什么分别呢？别急，让我先讲一下builder 模

意图动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。 结构图结构图好像和Composite模式有点像。确实是，我们后面再讲Decorator和Composite模式的关系。从结构图中我们可以看出Decorator的子类可以对Component进行一些扩充。这也就是Decorator模式的作用：对一个现有的类进行扩充来满足更多的

外观模式还是相当普遍的，先来看看几个例子：1. 一台电脑有很多东西组成，包括硬件，软件。硬件又包含主板，CPU，内存什么的，软件又包含操作系统，操作系统里面又有一大堆非常复杂的驱动，各个驱动之间又有很多关系。那么我们怎么启动这么复杂的一个东西呢？我们所要做的就是按一下电源开关。当用户按下电源开关后，操作系统会把电脑运行起来，中间过程那是相当的复杂。对于用户来说，电源开关就是一个简单使用的接口，

享元模式的英文是flyweight pattern，不知道哪位大哥第一个把flyweight翻译成享元的，真牛，翻译的很形象。个人认为享元模式还是挺复杂的。面向对象编程给我们带来了非常多的好处，但是同时它也有弊端，如果一个系统拥有非常非常多的对象，那么内存消耗会比较大，而且比较难管理。比如：1. 游戏里面的粒子系统，大量的微粒，如果为每个微粒创建一个对象的话，那么对象数量是相当的恐怖；

代理模式，PROXY。这是一个比较常用的结构型模式。个人比较喜欢这个模式，代理模式一个比较出名的应用就是智能指针。 意图为其他对象提供一个代理以控制对这个对象的访问。 结构图 一眼看去是不是和Decorator（装饰模式）很像？是啊，从结构图看，确实很像，或者说几乎一样。虽说它们的结构图很像，但是它们的意图完全不一样：装饰模式是为了给对象增加功能而代理模式是为了控制

我们介绍完了所有GOF设计模式书上的7种结构型设计模式，又到了总结的时候了。如果回顾一下这7种结构型设计模式，我们会发现有些模式很类似。是的，从结构来看确实很像。但是我们讲设计模式很多时候是从设计者的意图来区分的，单从代码结构来看可能是很类似，但是意图完全不一样。 Adapter，Bridge，FacadeAdapter：目的是为了解决不同接口类库之间不能一起工作的问题。Adapt

从本文开始我们来介绍行为模式。根据GOF的说法，设计模式可以分为：创建型模式，结构型模式和行为型模式。行为型模式涉及到算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信。我们先来介绍第一种行为型模式：职责链。 意图使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为

到目前为止，我都没有自己去使用过迭代器模式。个人感觉迭代器模式一般用在数据结构的遍历，比如list，map的元素遍历。因为我自己基本没有封装过这种数据结构，所以也没什么机会去使用迭代器模式（基本都是用stl或者boost的数据结构）。这里就copy一下GOF对于这种模式的定义：意图提供一种方法顺序访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示。

仁者见仁，知者见者。个人观点，无需纠结。http://www.youkuaiyun.com/article/2015-09-15/2825699