q351477的博客

什么是设计模式？设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。设计模式代表作《Design Patterns elements of Reusable Object-Oriented Software》鼎鼎大名的GoF写的书，业内无人不知，建议使用过设计模式之后，再看这本书，会比较好理解，对初学者不太友好。

意图允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。适用性一个对象的行为取决于它的状态。并且它必须在运行时刻根据状态改变它的行为。一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常，有多个操作包含这一相同的条件结构。State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。类图例子场景实现输出...

意图提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。动机一个聚合对象，如list，应该提供一种方法来让别人可以访问它的元素，而又不需要暴露它的内部结构，此外，针对不同的需要，可能要以不同的方式遍历这个列表。但是即使可以预见到所需的那些遍历操作，你可能也不希望列表的接口中充斥着各种不同遍历的操作。有时还可能需要在同一个列表上同时进行多个遍历。适用性访问一个聚合对象的内容而无需暴露它的内部表示。支持对聚合对象的多种遍历。为遍历不同的聚合结构提供一个统一的接口类图例

意图定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。该模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。适用性一次性实现一个算法的不变的部分，并将可变的行为留給子类来实现。各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。首先识别现在代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。控制子类扩展。模板方法只在特定点调用“hook”操作，这样就只允许在这些点进行扩展。类图例子场景咖啡冲泡法

意图为子系统中的一组接口提供一个一致的界面，该模式定义了一个高层接口，这个接口使得子系统更加容易使用。动机将一个子系统划分成为若干个子系统有利于降低系统的复杂度。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一就是引入一个外观对象，它为子系统中较一般的设备提供了一个单一而简单的界面。适用性当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也

意图将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作动机有时，为复用而设计的工具箱不能够被复用的原因仅仅是因为它的接口与专业应用领域所需要的接口不匹配。适用性你想使用一个已经存在的类，而它的接口不符合你的需求。你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作。（仅适用于对象Adapter）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。类

意图将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录日志，以及支持可撤销的操作。动机有时必须向某对象提交请求，但并不知道关于被请求的操作或请求的接收者的任何信息。例如，用户界面工具箱包括按钮和菜单这样的对象，它们执行请求相应用户输入。但工具箱不能显式的在按钮或菜单中实现该请求，因为只有使用工具箱的应用知道该由哪个对象做哪个操作。而工具箱的设计者无法知道请求的接收者或执行的操作。适用性在不同的时刻指定、排列和执行请求。支持撤销操作。支持修改日志，这样当系统崩溃

意图提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们的具体类动机考虑一个支持多种视感标准的用户界面工具包，列如Motif和Presentation Manager。不同的视感风格为诸如滚动条、窗口和按钮等用户界面“窗口组件”定义不同的外观和行为。为保证视感风格标准间的可移植性，一个应用不应该为特定的视感外观硬编码它的窗口组件。在整个应用中实例化特定视感风格的窗口组件类将使得以后很难改变视感风格。适用性一个系统要独立于它的产品的创建、组合和表示时。一个系统要由多个产品系列中的一个来配置

意图定义一个用于创建对象的接口，让子类决定实例化哪一个类。该模式使一个类的实例化延迟到其子类。动机框架使用抽象类定义和维护对象之间的关系。这些对象的创建通常也由框架负责。适用性当一个类不知道它所必须创建的对象的类的时候。当一个类希望由它的子类来指定它创建的对象的时候。当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。类图例子场景实现输出...

意图动态地给一个对象添加一些额外的职责。就增加功能来说，该模式相比生成子类更为灵活。动机有时我们希望给某个对象而不是整个类添加一些功能。例如，一个图形用户界面工具箱允许你对任意一个用户界面组件添加一些特性，例如边框，或是一些行为，例如窗口滚动；使用继承机制是添加功能的一种有效途径，从其他类继承过来的边框特性可以被子类的实例所使用。但这种方法不够灵活，因为边框的选择是静态的，用户不能控制对组件加边框的方式和时机。...

意图定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。动机将一个系统分割成一系列相互协作的类有一个常见的副作用：需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，因为这样降低了它们的可重用性。适用性当一个抽象模型有两个方面，其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变。当一个对象必须通知其他对象，而它又不能假

意图定义一系列的算法，把它们一个一个封装卡里，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。动机需要换行功能的客户程序如果直接包含换行算法代码的话讲会变得复杂，这使得客户程序庞大并且难以维护，尤其当其需要支持多种换行算法时问题会更加严重。不同的时候需要不同的算法，我们不想支持我们并不使用的换行算法。当换行功能时客户程序的一个难以分割的成分时，增加新的换行算法或改变现在算法将十分困难。...

意图保证一个类仅有一个实例，并提供一个访问它的全局访问点。动机对一些类来说，只有一个实例时很重要的。虽然系统中可以有许多打印机，但却只应该有一个打印假脱机，只应该有一个文件系统和一个窗口管理器。一个数字滤波器智能有一个A/D转换器。一个会计系统只能专用于一个公司。适用性当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。类图例子场景假设我们需要一个消息管理类，管理系统的全部消息。实现