qq_44632658的博客

访问者是一种行为设计模式，它能将算法与其所作用的对象隔离开来。假如你的团队开发了一款能够使用巨型图像中地理信息的应用程序。图像中的每个节点既能代表复杂实体（例如一座城市）， 也能代表更精细的对象（例如工业区和旅游景点等）。如果节点代表的真实对象之间存在公路，那么这些节点就会相互连接。在程序内部，每个节点的类型都由其所属的类来表示，每个特定的节点则是一个对象。一段时间后， 你接到了实现将图像导出到 XML 文件中的任务。这些工作最初看上去非常简单。

模板方法是一种行为设计模式它在超类中定义了一个算法的框架，允许子类在不修改结构　的情况下重写算法的特定步骤。假如你正在开发一款分析公司文档的数据挖掘程序。用户需要向程序输入各种格式（PDF、DOC 或 CSV）的文档，程序则会试图从这些文件中抽取有意义的数据，并以统一的格式将其返回给用户。该程序的首个版本仅支持 DOC 文件。在接下来的一个版本中，程序能够支持 CSV 文件。一个月后，你“教会”了程序从 PDF 文件中抽取数据。一段时间后，你发现这三个类中包含许多相似代码。

策略是一种行为设计模式，它能让你定义一系列算法，并将每种算法分别放入独立的类中，以使算法的对象能够相互替换。你打算为游客们创建一款导游程序。该程序的核心功能是提供美观的地图，以帮助用户在任何城市中快速定位。用户期待的程序新功能是自动路线规划：他们希望输入地址后就能在地图上看到前往目的地的最快路线。程序的首个版本只能规划公路路线。驾车旅行的人们对此非常满意。但很显然，并非所有人都会在度假时开车。因此你在下次更新时添加了规划步行路线的功能。此后，你又添加了规划公共交通路线的功能。而这只是个开始。

状态是一种行为设计模式，让你能在一个对象的内部状态变化时改变其行为，使其看上去就像改变了自身所属的类一样。状态模式与有限状态机的概念紧密相关。其主要思想是程序在任意时刻仅可处于几种有限的状态中。在任何一个特定状态中，程序的行为都不相同，且可瞬间从一个状态切换到另一个状态。不过，根据当前状态，程序可能会切换到另外一种状态，也可能会保持当前状态不变。这些数量有限且预先定义的状态切换规则被称为转移。你还可将该方法应用在对象上。

观察者是一种行为设计模式，允许你定义一种订阅机制，可在对象事件发生时通知多个“观察”该对象的其他对象。假如你有两种类型的对象：“顾客”和“商店”。顾客对某个特定品牌的产品非常感兴趣（例如最新型号的 iPhone 手机），而该产品很快将会在商店里出售。一方面顾客可以每天来商店看看产品是否到货。但如果商品尚未到货时，绝大多数来到商店的顾客都会空手而归。另一方面，每次新产品到货时，商店可以向所有顾客发送邮件（可能会被视为垃圾邮件）。这样，部分顾客就无需反复前往商店了，但也可能会惹恼对新产品没有兴趣的其他顾客。

备忘录是一种行为设计模式，允许在不暴露对象实现细节的情况下保存和恢复对象之前的状态。假设你正在开发一款文字编辑器应用程序，除了简单的文字编辑功能外，编辑器中还要有设置文本格式和插入内嵌图片等功能。后来你决定让用户能撤销施加在文本上的任何操作。你选择采用最直接的方式来实现该功能：程序在执行任何操作前会记录所有的对象状态， 并将其保存下来。当用户此后需要撤销某个操作时，程序将从历史记录中获取最近的快照，然后使用它来恢复所有对象的状态。

迭代器是一种行为设计模式，让你能在不暴露集合底层表现形式（列表、栈和树等）的情况下遍历集合中所有的元素。大部分集合使用简单列表存储元素。但有些集合还会使用栈、树、图和其他复杂的数据结构。无论集合的构成方式如何，它都必须提供某种访问元素的方式，便于其他代码使用其中的元素。集合应提供一种能够遍历元素的方式，且保证它不会周而复始地访问同一个元素。如果你的集合基于列表， 那么这项工作听上去仿佛很简单。但如何遍历复杂数据结构（例如树）中的元素呢？

命令是一种行为设计模式它可将请求转换为一个包含与请求相关的所有信息的独立对象。该转换让你能根据不同的请求将方法参数化、延迟请求执行或将其放入队列中，且能实现可撤销操作。假如你正在开发一款新的文字编辑器，当前的任务是创建一个包含多个按钮的工具栏，并让每个按钮对应编译器的不同操作。你创建了一个「Button」类。它不仅用于生成工具栏上的按钮，还可用于生成各种对话框的通用按钮。尽管所有按钮看上去都很相似，但它们可以完成不同的操作（打开、保存、打印和应用等）。你会在哪里放置这些按钮的点击处理代码呢？最。

责任链是一种行为设计模式允许你将请求沿着处理者链进行发送。收到请求后，每个处理者均可对请求进行处理，或将其传递给链上的下个处理者。假如你正在开发一个在线订购系统。你希望对系统访问进行限制，只允许认证用户创建订单。此外，拥有管理权限的用户也拥有所有订单的完全访问权限。简单规划后，你会意识到这些检查必须依次进行。只要接收到包含用户凭据的请求，应用程序就可尝试对进入系统的用户进行认证。但如果由于用户凭据不正确而导致认证失败，那就没有必要进行后续检查了。

代理是一种结构型设计模式让你能够提供对象的替代品或其占位符。代理控制着对于原对象的访问，并允许在将请求提交给对象前后进行一些处理。举个例子：有这样一个消耗大量系统资源的巨型对象， 你只是偶尔需要使用它，并非总是需要。你可以实现延迟初始化：在实际有需要时再创建该对象。对象的所有客户端都要执行延迟初始代码。不幸的是，这很可能会带来很多重复代码。在理想情况下，我们希望将代码直接放入对象的类中，但这并非总是能实现：比如类可能是第三方封闭库的一部分。

享元是一种结构型设计模式，它摒弃了在每个对象中保存所有数据的方式，通过共享多个对象所共有的相同状态，让你能在有限的内存容量中载入更多对象。假如你希望在长时间工作后放松一下，所以开发了一款简单的游戏：玩家们在地图上移动并相互射击。你决定实现一个真实的粒子系统，并将其作为游戏的特色。大量的子弹、导弹和爆炸弹片会在整个地图上穿行，为玩家提供紧张刺激的游戏体验。开发完成后，你推送提交了最新版本的程序，并在编译游戏后将其发送给了一个朋友进行测试。

外观是一种结构型设计模式能为程序库、框架或其他复杂类提供一个简单的接口。假设你必须在代码中使用某个复杂的库或框架中的众多对象。正常情况下，你需要负责所有对象的初始化工作、管理其依赖关系并按正确的顺序执行方法等。最终，程序中类的业务逻辑将与第三方类的实现细节紧密耦合，使得理解和维护代码的工作很难进行。

装饰是一种结构型设计模式，允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。假设你正在开发一个提供通知功能的库，其他程序可使用它向用户发送关于重要事件的通知。库的最初版本基于通知器Notifier 类，其中只有很少的几个成员变量，一个构造函数和一个send 发送方法。该方法可以接收来自客户端的消息参数，并将该消息发送给一系列的邮箱，邮箱列表则是通过构造函数传递给通知器的。作为客户端的第三方程序仅会创建和配置通知器对象一次，然后在有重要事件发生时对其进行调用。

组合是一种结构型设计模式，你可以使用它将对象组合成树状结构，并且能像使用独立对象一样使用它们。如果应用的核心模型能用树状结构表示，在应用中使用组合模式才有价值。例如你有两类对象：产品和盒子。一个盒子中可以包含多个产品或者几个较小的盒子。这些小盒子中同样可以包含一些产品或者更小的盒子。假设你希望在这些类的基础上开发一个订购系统。订单中可以包含无包装的简单产品，也可以包含装满产品的盒子。此时你会如何计算每张订单的总价格呢？

桥接是一种结构型设计模式，可将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构，从而能在开发时分别使用。假如你有一个几何形状（Shape）类， 从它能扩展出两个子类： 圆形（Circle）和方形（Square）。你希望对这样的类层次结构进行扩展以使其包含颜色， 所以你打算创建名为红色（Red）和蓝色（Blue）的形状子类。但是，由于你已有两个子类，所以总共需要创建四个类才能覆盖所有组合，例如蓝色圆形（BlueCircle）和红色方形（RedSquare）。

适配器是一种结构型设计模式，它能使接口不兼容的对象能够相互合作。假如你正在开发一款股票市场监测程序，它会从不同来源下载 XML 格式的股票数据，然后向用户呈现出美观的图表。在开发过程中， 你决定在程序中整合一个第三方智能分析函数库。但是遇到了一个问题， 那就是分析函数库只兼容JSON 格式的数据。你可以修改程序库来支持XML。但是，这可能需要修改部分依赖该程序库的现有代码。甚至还有更糟糕的情况，你可能根本没有程序库的源代码，从而无法对其进行修改。

单例是一种创建型设计模式，让你能够保证一个类只有一个实例，并提供一个访问该实例的全局节点。保证一个类只有一个实例。为该实例提供一个全局访问节点。为什么会有人想要控制一个类所拥有的实例数量？最常见的原因是控制某些共享资源（例如数据库或文件）的访问权限。它的运作方式是这样的：如果你创建了一个对象，同时过一会儿后你决定再创建一个新对象，此时你会获得之前已创建的对象，而不是一个新对象。注意，普通构造函数无法实现上述行为，因为构造函数的设计决定了它必须总是返回一个新对象。

原型是一种创建型设计模式，使你能够复制已有对象，而又无需使代码依赖它们所属的类。如果你有一个对象，并希望生成与其完全相同的一个复制品，你该如何实现呢？首先，你必须新建一个属于相同类的对象。然后，你必须遍历原始对象的所有成员变量，并将成员变量值复制到新对象中。不错！但有个小问题。并非所有对象都能通过这种方式进行复制，因为有些对象可能拥有私有成员变量，它们在对象本身以外是不可见的。直接复制还有另外一个问题。因为你必须知道对象所属的类才能创建复制品，所以代码必须依赖该类。

生成器是一种创建型设计模式，使你能够分步骤创建复杂对象。该模式允许你使用相同的创建　代码生成不同类型和形式的对象。假设有这样一个复杂对象，在对其进行构造时需要对诸多成员变量和嵌套对象进行繁复的初始化工作。这些初始化代码通常深藏于一个包含众多参数且让人基本看不懂的构造函数中；甚至还有更糟糕的情况，那就是这些代码散落在客户端代码的多个位置。如果为每种可能的对象都创建一个子类，这可能导致程序过于复杂：例如， 我们来思考如何创建一个房屋（House）对象。建造一栋简单的房屋，首先你需要建造四面墙和地板。

抽象工厂模式

工厂方法是一种创建型设计模式，其在父类中提供一个创建对象的方法，允许子类决定实例化对象的类型。假设你正在开发一款物流管理应用。最初版本只能处理卡车运输，因此大部分代码都在位于名为“卡车”的类中。一段时间后，这款应用变得极受欢迎。你每天都能收到十几次来自海运公司的请求，希望应用能够支持海上物流功能。这可是个好消息。但是代码问题该如何处理呢？目前，大部分代码都与 卡车 类相关。在程序中添加 轮船 类需要修改全部代码。

uml类图