设计模式-进阶架构师必备知识（一篇读懂，就一篇）

目录

设计模式

1.1 设计模式从何而来

1.2 设计模式是什么

1.3 设计模式有什么用

1.4 设计模式的七大原则

1.4.1 单一职责原则（Single Responsibility Principle）

1.4.2 开闭原则（Open Close Principle）

1.4.3 里氏代换原则（Liskov Substitution Principle）

1.4.4 依赖倒转原则（Dependence Inversion Principle）

1.4.5 接口隔离原则（Interface Segregation Principle）

1.4.6 迪米特法则（最少知道原则）（Demeter Principle）

1.4.7 合成复用原则（Composite Reuse Principle）

1.5 创建型模式（6个）

1.5.1 简单工厂模式【学习难度：★★☆☆☆，使用频率：★★★☆☆】

1.5.2 工厂方法模式【学习难度：★★☆☆☆，使用频率：★★★★★】

1.5.3 抽象工厂模式【学习难度：★★★★☆，使用频率：★★★★★】

1.5.4 单例模式【学习难度：★☆☆☆☆，使用频率：★★★★☆】

1.5.5 原型模式【学习难度：★★★☆☆，使用频率：★★★☆☆】

1.5.6 建造者模式【学习难度：★★★★☆，使用频率：★★☆☆☆】

1.6 结构型模式（7个）

1.6.1 适配器模式【学习难度：★★☆☆☆，使用频率：★★★★☆】

1.6.2 桥接模式【学习难度：★★★☆☆，使用频率：★★★☆☆】

1.6.3 组合模式【学习难度：★★★☆☆，使用频率：★★★★☆】

1.6.4 装饰模式【学习难度：★★★☆☆，使用频率：★★★☆☆】

1.6.5 外观模式【学习难度：★☆☆☆☆，使用频率：★★★★★】

1.6.6 享元模式【学习难度：★★★★☆，使用频率：★☆☆☆☆】

1.6.7 代理模式【学习难度：★★★☆☆，使用频率：★★★★☆】

1.7 行为型模式（11）

1.7.1 责任链模式【学习难度：★★★☆☆，使用频率：★★☆☆☆】

1.7.2 命令模式【学习难度：★★★☆☆，使用频率：★★★★☆】

1.7.3 解释器模式【学习难度：★★★★★，使用频率：★☆☆☆☆】

1.7.4 迭代器模式【学习难度：★★★☆☆，使用频率：★★★★★】

1.7.5 中介者模式【学习难度：★★★☆☆，使用频率：★★☆☆☆】

1.7.6 备忘录模式【学习难度：★★☆☆☆，使用频率：★★☆☆☆】

1.7.7 观察者模式【学习难度：★★★☆☆，使用频率：★★★★★】

1.7.8 状态模式【学习难度：★★★☆☆，使用频率：★★★☆☆】

1.7.9 策略模式【学习难度：★☆☆☆☆，使用频率：★★★★☆】

1.7.10 模板方法模式【学习难度：★★☆☆☆，使用频率：★★★☆☆】

1.7.11 访问者模式【学习难度：★★★★☆，使用频率：★☆☆☆☆】

---

设计模式

声明：本文章内容来源于网络，经本人整合后产生，仅作为学习交流使用，不涉及任何商业用途，如侵权，请联系：[email protected]

        关于金庸小说中到底是招式重要还是内功重要的争论从未停止，我们在这里并不分析张无忌的九阳神功和令狐冲的独孤九剑到底哪个更厉害，但我想每个武林人士梦寐以求的应该是既有淋漓的招式又有深厚的内功。看到这里大家可能会产生疑问了？搞什么，讨论什么招式与内功，我只是个软件开发人员。别急，正因为你是软件开发人员我才跟你谈这个，因为我们的软件开发技术也包括一些招式和内功：Java、C#、C++等编程语言Eclipse、Visual Studio等开发工具，JSP、ASP.net等开发技术，Struts、Hibernate、JBPM等框架技术，所有这些我们都可以认为是招式；而数据结构、算法、设计模式、重构、软件工程等则为内功。招式可以很快学会，但是内功的修炼需要更长的时间。我想每一位软件开发人员也都希望成为一名兼具淋漓招式和深厚内功的“上乘”软件工程师，而对设计模式的学习与领悟将会让你“内功”大增，再结合你日益纯熟的“招式”，你的软件开发“功力”一定会达到一个新的境界。既然这样，还等什么，赶快行动吧。下面就让我们正式踏上神奇而又美妙的设计模式之旅。 

1.1 设计模式从何而来

        在介绍设计模式的起源之前，我们先要了解一下模式的诞生与发展。与很多软件工程技术一样，模式起源于建筑领域，毕竟与只有几十年历史的软件工程相比，已经拥有几千年沉淀的建筑工程有太多值得学习和借鉴的地方。

        那么模式是如何诞生的？让我们先来认识一个人——Christopher Alexander（克里斯托弗.亚历山大），哈佛大学建筑学博士、美国加州大学伯克利分校建筑学教授、加州大学伯克利分校环境结构研究所所长、美国艺术和科学院院士……头衔真多，不过他还有一个“昵称”——模式之父(The father of patterns)。Christopher Alexander博士及其研究团队用了约20年的时间，对住宅和周边环境进行了大量的调查研究和资料收集工作，发现人们对舒适住宅和城市环境存在一些共同的认同规律，Christopher Alexander在著作A Pattern Language: Towns, Buildings, Construction中把这些认同规律归纳为253个模式，对每一个模式(Pattern)都从Context（前提条件）、Theme或Problem（目标问题）、 Solution（解决方案）三个方面进行了描述，并给出了从用户需求分析到建筑环境结构设计直至经典实例的过程模型。

        在Christopher Alexander的另一部经典著作《建筑的永恒之道》中，他给出了关于模式的定义：

        每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的成功的解决方案，无须再重复相同的工作。这个定义可以简单地用一句话表示：

        模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案。【A pattern is a successful or efficient solution to a recurring problem within a context】

1.2 设计模式是什么

        俗话说：站在别人的肩膀上，我们会看得更远。设计模式的出现可以让我们站在前人的肩膀上，通过一些成熟的设计方案来指导新项目的开发和设计，以便于我们开发出具有更好的灵活性和可扩展性，也更易于复用的软件系统。

        设计模式的一般定义如下：

        设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且保证代码可靠性。

        狭义的设计模式是指GoF在《设计模式：可复用面向对象软件的基础》一书中所介绍的23种经典设计模式，不过设计模式并不仅仅只有这23种，随着软件开发技术的发展，越来越多的新模式不断诞生并得以应用。

        设计模式一般包含模式名称、问题、目的、解决方案、效果等组成要素，其中关键要素是模式名称、问题、解决方案和效果。模式名称(Pattern Name)通过一两个词来描述模式的问题、解决方案和效果，以便更好地理解模式并方便开发人员之间的交流，绝大多数模式都是根据其功能或模式结构来命名的（GoF设计模式中没有一个模式用人名命名）；问题(Problem)描述了应该在何时使用模式，它包含了设计中存在的问题以及问题存在的原因；解决方案(Solution)描述了一个设计模式的组成成分，以及这些组成成分之间的相互关系，各自的职责和协作方式，通常解决方案通过UML类图和核心代码来进行描述；效果(Consequences)描述了模式的优缺点以及在使用模式时应权衡的问题。

        虽然GoF设计模式只有23个，但是它们各具特色，每个模式都为某一个可重复的设计问题提供了一套解决方案。根据它们的用途，设计模式可分为创建型(Creational)，结构型(Structural)和行为型(Behavioral)三种，其中创建型模式主要用于描述如何创建对象，结构型模式主要用于描述如何实现类或对象的组合，行为型模式主要用于描述类或对象怎样交互以及怎样分配职责，在GoF 23种设计模式中包含5种创建型设计模式、7种结构型设计模式和11种行为型设计模式。此外，根据某个模式主要是用于处理类之间的关系还是对象之间的关系，设计模式还可以分为类模式和对象模式。我们经常将两种分类方式结合使用，如单例模式是对象创建型模式，模板方法模式是类行为型模式。

        值得一提的是，有一个设计模式虽然不属于GoF 23种设计模式，但一般在介绍设计模式时都会对它进行说明，它就是简单工厂模式，也许是太“简单”了，GoF并没有把它写到那本经典著作中，不过现在大部分的设计模式书籍都会对它进行专门的介绍。

        表1列出将要介绍的24种设计模式，其中模式的学习难度是我个人在多年模式使用和推广过程中的经验总结，仅作参考，模式的使用频率来自著名的模式推广和教育网站——http://www.dofactory.net。

表1 常用设计模式一览表

类型	模式名称	学习难度	使用频率
创建型模式 Creational Pattern	单例模式 Singleton Pattern	★☆☆☆☆	★★★★☆
	简单工厂模式 Simple Factory Pattern	★★☆☆☆	★★★☆☆
	工厂方法模式 Factory Method Pattern	★★☆☆☆	★★★★★
	抽象工厂模式 Abstract  Factory Pattern	★★★★☆	★★★★★
	原型模式 Prototype Pattern	★★★☆☆	★★★☆☆
	建造者模式 Builder Pattern	★★★★☆	★★☆☆☆
结构型模式 Structural Pattern	适配器模式 Adapter Pattern	★★☆☆☆	★★★★☆
	桥接模式 Bridge  Pattern	★★★☆☆	★★★☆☆
	组合模式 Composite  Pattern	★★★☆☆	★★★★☆
	装饰模式 Decorator  Pattern	★★★☆☆	★★★☆☆
	外观模式 Façade  Pattern	★☆☆☆☆	★★★★★
	享元模式 Flyweight  Pattern	★★★★☆	★☆☆☆☆
	代理模式 Proxy  Pattern	★★★☆☆	★★★★☆
行为型模式 Behavioral Pattern	职责链模式 Chain  of Responsibility Pattern	★★★☆☆	★★☆☆☆
	命令模式 Command  Pattern	★★★☆☆	★★★★☆
	解释器模式 Interpreter  Pattern	★★★★★	★☆☆☆☆
	迭代器模式 Iterator  Pattern	★★★☆☆	★★★★★
	中介者模式 Mediator  Pattern	★★★☆☆	★★☆☆☆
	备忘录模式 Memento  Pattern	★★☆☆☆	★★☆☆☆
	观察者模式 Observer  Pattern	★★★☆☆	★★★★★
	状态模式 State  Pattern	★★★☆☆	★★★☆☆
	策略模式 Strategy  Pattern	★☆☆☆☆	★★★★☆
	模板方法模式 Template  Method Pattern	★★☆☆☆	★★★☆☆
	访问者模式 Visitor  Pattern	★★★★☆	★☆☆☆☆

1.3 设计模式有什么用

        设计模式到底有什么用？简单来说，设计模式至少有如下几个用途：

        (1) 设计模式来源众多专家的经验和智慧，它们是从许多优秀的软件系统中总结出的成功的、能够实现可维护性复用的设计方案，使用这些方案将可以让我们避免做一些重复性的工作，也许我们冥思苦想得到的一个“自以为很了不起”的设计方案其实就是某一个设计模式。在时间就是金钱的今天，设计模式无疑会为有助于我们提高开发和设计效率，但它不保证一定会提高。

        (2) 设计模式提供了一套通用的设计词汇和一种通用的形式来方便开发人员之间沟通和交流，使得设计方案更加通俗易懂。交流通常很耗时，任何有助于提高交流效率的东西都可以为我们节省不少时间。无论你使用哪种编程语言，做什么类型的项目，甚至你处于一个国际化的开发团队，当面对同一个设计模式时，你和别人的理解并无二异，因为设计模式是跨语言、跨平台、跨应用、跨国界的。

        (3) 大部分设计模式都兼顾了系统的可重用性和可扩展性，这使得我们可以更好地重用一些已有的设计方案、功能模块甚至一个完整的软件系统，避免我们经常做一些重复的设计、编写一些重复的代码。此外，随着软件规模的日益增大，软件寿命的日益变长，系统的可维护性和可扩展性也越来越重要，许多设计模式将有助于提高系统的灵活性和可扩展性，让我们在不修改或者少修改现有系统的基础上增加、删除或者替换功能模块。如果一点设计模式都不懂，我想要做到这一点恐怕还是很困难的。

        (4) 合理使用设计模式并对设计模式的使用情况进行文档化，将有助于别人更快地理解系统。如果某一天因为升职或跳槽等原因，别人接手了你的项目，只要他也懂设计模式，我想他应该能够很快理解你的设计思路和实现方案，让你升职无后患之忧，跳槽也心安理得，何乐而不为呢？

        (5) 最后一点对初学者很重要，学习设计模式将有助于初学者更加深入地理解面向对象思想，让你知道：如何将代码分散在几个不同的类中？为什么要有“接口”？何谓针对抽象编程？何时不应该使用继承？如果不修改源代码增加新功能？同时还让你能够更好地阅读和理解现有类库（如JDK）与其他系统中的源代码，让你早点脱离面向对象编程的“菜鸟期”。

个人观点

        作为设计模式的忠实粉丝和推广人员，在正式学习设计模式之前，我结合多年的模式应用和教育培训经验与大家分享几点个人的看法，以作参考：

        (1) 掌握设计模式并不是件很难的事情，关键在于多思考，多实践，不要听到人家说懂几个设计模式就很“牛”，只要用心学习，设计模式也就那么回事，你也可以很“牛”的，一定要有信心。

        (2) 在学习每一个设计模式时至少应该掌握如下几点：这个设计模式的意图是什么，它要解决一个什么问题，什么时候可以使用它；它是如何解决的，掌握它的结构图，记住它的关键代码；能够想到至少两个它的应用实例，一个生活中的，一个软件中的；这个模式的优缺点是什么，在使用时要注意什么。当你能够回答上述所有问题时，恭喜你，你了解一个设计模式了，至于掌握它，那就在开发中去使用吧，用多了你自然就掌握了。

        (3) “如果想体验一下运用模式的感觉，那么最好的方法就是运用它们”。正如在本章最开始所说的，设计模式是“内功心法”，它还是要与“实战招式”相结合才能够相得益彰。学习设计模式的目的在于应用，如果不懂如何使用一个设计模式，而只是学过，能够说出它的用途，绘制它的结构，充其量也只能说你了解这个模式，严格一点说：不会在开发中灵活运用一个模式基本上等于没学。所以一定要做到：少说多做。

        (4) 千万不要滥用模式，不要试图在一个系统中用上所有的模式，也许有这样的系统，但至少目前我没有碰到过。每个模式都有自己的适用场景，不能为了使用模式而使用模式？【怎么理解，大家自己思考】，滥用模式不如不用模式，因为滥用的结果得不到“艺术品”一样的软件，很有可能是一堆垃圾代码。

        (5) 如果将设计模式比喻成“三十六计”，那么每一个模式都是一种计策，它为解决某一类问题而诞生，不管这个设计模式的难度如何，使用频率高不高，我建议大家都应该好好学学，多学一个模式也就意味着你多了“一计”，说不定什么时候一不小心就用上了，因此，模式学习之路上要不怕困难，勇于挑战，有的模式虽然难一点，但反复琢磨，反复研读，应该还是能够征服的。

        (6) 设计模式的“上乘”境界：“手中无模式，心中有模式”。模式使用的最高境界是你已经不知道具体某个设计模式的定义和结构了，但你会灵活自如地选择一种设计方案【其实就是某个设计模式】来解决某个问题，设计模式已经成为你开发技能的一部分，能够手到擒来，“内功”与“招式”已浑然一体，要达到这个境界并不是看完某本书或者开发一两个项目就能够实现的，它需要不断沉淀与积累，所以，对模式的学习不要急于求成。

        (7) 最后一点来自GoF已故成员、我个人最尊敬和崇拜的软件工程大师之一John Vlissides的著作《设计模式沉思录》(Pattern Hatching Design Patterns Applied)：模式从不保证任何东西，它不能保证你一定能够做出可复用的软件，提高你的生产率，更不能保证世界和平，模式并不能替代人来完成软件系统的创造，它们只不过会给那些缺乏经验但却具备才能和创造力的人带来希望。

扩展

John Vlissides（1961-2005），GoF成员，斯坦福大学计算机科学博士，原IBM研究员，因患脑瘤于2005年11月24日（感恩节）病故，享年44岁，为纪念他的贡献，ACM SIGPLAN特设立John Vlissides奖。

1.4 设计模式的七大原则

1.4.1 单一职责原则（Single Responsibility Principle）

        一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

1.4.2 开闭原则（Open Close Principle）

        一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

1.4.3 里氏代换原则（Liskov Substitution Principle）

        所有引用基类（父类）的地方必须能透明地使用其子类的对象。

1.4.4 依赖倒转原则（Dependence Inversion Principle）

        抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

1.4.5 接口隔离原则（Interface Segregation Principle）

        使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

1.4.6 迪米特法则（最少知道原则）（Demeter Principle）

        一个软件实体应当尽可能少地与其他实体发生相互作用。

1.4.7 合成复用原则（Composite Reuse Principle）

        尽量使用对象组合，而不是继承来达到复用的目的。

1.5 创建型模式（6个）

1.5.1 简单工厂模式【学习难度：★★☆☆☆，使用频率：★★★☆☆】

        简单工厂模式(Simple Factory Pattern)：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。因为在简单工厂模式中用于创建实例的方法是静态(static)方法，因此简单工厂模式又被称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。

1.5.2 工厂方法模式【学习难度：★★☆☆☆，使用频率：★★★★★】

        在工厂方法模式中，我们不再提供一个统一的工厂类来创建所有的产品对象，而是针对不同的产品提供不同的工厂，系统提供一个与产品等级结构对应的工厂等级结构。工厂方法模式定义如下：

        工厂方法模式(Factory Method Pattern)：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。工厂方法模式又简称为工厂模式(Factory Pattern)，又可称作虚拟构造器模式(Virtual Constructor Pattern)或多态工厂模式(Polymorphic Factory Pattern)。工厂方法模式是一种类创建型模式。

1.5.3 抽象工厂模式【学习难度：★★★★☆，使用频率：★★★★★】

        抽象工厂模式为创建一组对象提供了一种解决方案。与工厂方法模式相比，抽象工厂模式中的具体工厂不只是创建一种产品，它负责创建一族产品。抽象工厂模式定义如下：

        抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，它是一种对象创建型模式。

1.5.4 单例模式【学习难度：★☆☆☆☆，使用频率：★★★★☆】

        单例模式(Singleton Pattern)：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。

1.5.5 原型模式【学习难度：★★★☆☆，使用频率：★★★☆☆】

        在使用原型模式时，我们需要首先创建一个原型对象，再通过复制这个原型对象来创建更多同类型的对象。试想，如果连孙悟空的模样都不知道，怎么拔毛变小猴子呢？原型模式的定义如下：

        原型模式(Prototype Pattern)：使用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式是一种对象创建型模式。

1.5.6 建造者模式【学习难度：★★★★☆，使用频率：★★☆☆☆】

        建造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。

1.6 结构型模式（7个）

1.6.1 适配器模式【学习难度：★★☆☆☆，使用频率：★★★★☆】

        适配器模式(Adapter Pattern)：将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。

        在适配器模式中，我们通过增加一个新的适配器类来解决接口不兼容的问题，使得原本没有任何关系的类可以协同工作。根据适配器类与适配者类的关系不同，适配器模式可分为对象适配器和类适配器两种，在对象适配器模式中，适配器与适配者之间是关联关系；在类适配器模式中，适配器与适配者之间是继承（或实现）关系。在实际开发中，对象适配器的使用频率更高。

1.6.2 桥接模式【学习难度：★★★☆☆，使用频率：★★★☆☆】

        桥接模式用一种巧妙的方式处理多层继承存在的问题，用抽象关联取代了传统的多层继承，将类之间的静态继承关系转换为动态的对象组合关系，使得系统更加灵活，并易于扩展，同时有效控制了系统中类的个数。桥接定义如下：

        桥接模式(Bridge Pattern)：将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。

1.6.3 组合模式【学习难度：★★★☆☆，使用频率：★★★★☆】

        组合模式(Composite Pattern)：组合多个对象形成树形结构以表示具有“整体—部分”关系的层次结构。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性，组合模式又可以称为“整体—部分”(Part-Whole)模式，它是一种对象结构型模式。

1.6.4 装饰模式【学习难度：★★★☆☆，使用频率：★★★☆☆】

        装饰模式(Decorator Pattern)：动态地给一个对象增加一些额外的职责，就增加对象功能来说，装饰模式比生成子类实现更为灵活。装饰模式是一种对象结构型模式。

1.6.5 外观模式【学习难度：★☆☆☆☆，使用频率：★★★★★】

        外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

1.6.6 享元模式【学习难度：★★★★☆，使用频率：★☆☆☆☆】

        享元模式(Flyweight Pattern)：运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式，它是一种对象结构型模式。

1.6.7 代理模式【学习难度：★★★☆☆，使用频率：★★★★☆】

        代理模式是常用的结构型设计模式之一，当无法直接访问某个对象或访问某个对象存在困难时可以通过一个代理对象来间接访问，为了保证客户端使用的透明性，所访问的真实对象与代理对象需要实现相同的接口。根据代理模式的使用目的不同，代理模式又可以分为多种类型，例如保护代理、远程代理、虚拟代理、缓冲代理等，它们应用于不同的场合，满足用户的不同需求。

代理模式：给某一个对象提供一个代理或占位符，并由代理对象来控制对原对象的访问。

1.7 行为型模式（11）

1.7.1 责任链模式【学习难度：★★★☆☆，使用频率：★★☆☆☆】

        职责链模式(Chain of Responsibility Pattern)：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。职责链模式是一种对象行为型模式。

1.7.2 命令模式【学习难度：★★★☆☆，使用频率：★★★★☆】

        命令模式可以将请求发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。

        命令模式定义如下：

        命令模式(Command Pattern)：将一个请求封装为一个对象，从而让我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。

1.7.3 解释器模式【学习难度：★★★★★，使用频率：★☆☆☆☆】

        解释器模式(Interpreter Pattern)：定义一个语言的文法，并且建立一个解释器来解释该语言中的句子，这里的“语言”是指使用规定格式和语法的代码。解释器模式是一种类行为型模式。

1.7.4 迭代器模式【学习难度：★★★☆☆，使用频率：★★★★★】

        迭代器模式(Iterator Pattern)：提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。

1.7.5 中介者模式【学习难度：★★★☆☆，使用频率：★★☆☆☆】

        中介者模式(Mediator Pattern)：用一个中介对象（中介者）来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者模式又称为调停者模式，它是一种对象行为型模式。

1.7.6 备忘录模式【学习难度：★★☆☆☆，使用频率：★★☆☆☆】

        备忘录模式(Memento Pattern)：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。它是一种对象行为型模式，其别名为Token。

1.7.7 观察者模式【学习难度：★★★☆☆，使用频率：★★★★★】

        观察者模式(Observer Pattern)：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式的别名包括发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。

1.7.8 状态模式【学习难度：★★★☆☆，使用频率：★★★☆☆】

        状态模式(State Pattern)：允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)，状态模式是一种对象行为型模式。

1.7.9 策略模式【学习难度：★☆☆☆☆，使用频率：★★★★☆】

        在策略模式中，我们可以定义一些独立的类来封装不同的算法，每一个类封装一种具体的算法，在这里，每一个封装算法的类我们都可以称之为一种策略(Strategy)，为了保证这些策略在使用时具有一致性，一般会提供一个抽象的策略类来做规则的定义，而每种算法则对应于一个具体策略类。

        策略模式的主要目的是将算法的定义与使用分开，也就是将算法的行为和环境分开，将算法的定义放在专门的策略类中，每一个策略类封装了一种实现算法，使用算法的环境类针对抽象策略类进行编程，符合“依赖倒转原则”。在出现新的算法时，只需要增加一个新的实现了抽象策略类的具体策略类即可。策略模式定义如下：

        策略模式(Strategy Pattern)：定义一系列算法类，将每一个算法封装起来，并让它们可以相互替换，策略模式让算法独立于使用它的客户而变化，也称为政策模式(Policy)。策略模式是一种对象行为型模式。

1.7.10 模板方法模式【学习难度：★★☆☆☆，使用频率：★★★☆☆】

        模板方法模式：定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

1.7.11 访问者模式【学习难度：★★★★☆，使用频率：★☆☆☆☆】

        访问者模式(Visitor Pattern):提供一个作用于某对象结构中的各元素的操作表示，它使我们可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式是一种对象行为型模式。