原文：
模式与设计的关系
每个模式都描述了某个特定场景中一个特定问题的约束因素/动机和关系，并为设计者提供一种解决这些问题的优雅方案。换句话说，模式仅仅是描述了特定场景下的关系和约束因素，正因如此，模式本身并不是最重要的，特定场景下的关系和约束因素才是最真实的，而模式仅仅是提供了一组描述这些关系的一组词汇，提供了一套解决这些关系的优雅方式而已。
在软件设计中，模式是随特定场景下的关系和约束因素而定的。也就是说，对所要解决问题的分析和理解是使用模式的必要条件。只有清楚了特定场景下的关系和约束因素，才能很好地选择解决问题的方法和适用的模式。
特定模式描述的是问题中概念(抽象类)之间的关系，比如所有的行为模式，bridge模式等；或者是抽象类和派生类之间的关系，比如Proxy，Composite，Decorator等；抑或是新类和原有类之间的关系，如Adaptor，Facade等。这些关系未必是显而易见的，它们都是问题分析的结果。没有从概念视角对问题的分析，这些关系是不能凸现出来的。因此，使用模式应该建立在共性与可变分析、分析矩阵等方法的基础上。在概念视角层次上的分析，往往考虑的是抽象类之间的关系，因此这时所采用的模式一般是行为模式、bridge模式等。描述抽象类和派生类之间关系的模式一般应该等到实现层次时才考虑引入。这种分层设计有助于简化设计过程，忽略不必要的次要因素，产生更好的高层设计。
根据上述观点，虽然模式经常是组合使用，但模式的使用顺序是有先后之分的。在高层设计会采用一些高层的主模式，在代码实现级别上，也会再次引入其他合适的模式。个人觉得行为模式、Bridge、Facade等模式是最常用的主模式。
模式与继承
（注：这里仅针对静态语言，在动态语言中，多态并非通过继承实现）
封装/继承/多态都是面向对象的基本概念。前面已经讲过，封装变化是模式的核心思想之一。同时，从抽象类和派生类的角度看，继承和多态使得抽象类能够封装派生类的类型。显然，继承和多态使类封装变化成为可能。因此，在设计模式中，继承是随处可见的。
从模式角度看，模式是面向对象复用的基础元素。采用模式可使设计的软件更加灵活，更易扩展，更易维护，这也正是OCP(开放封闭原则)所强调的。要实现这个目标，继承也是必不可少的。继承使派生类之间可互相替换，因此也就封装了抽象类背后的变化。
一般来说，使用模式是有代价的。模式虽有其自身的优越性，但只有在问题本身有一定的复杂性时，采用模式来简化这些复杂性才是有意义的。然而，不能忽略的是：模式本身(所涉及的相互交互的类)是有一定复杂性的。每个模式中相互交互的类之间，可以说是紧密耦合在一起的。这些类基本上是不可分的，它们本身就是作为一个整体而存在。同时这些类背后的继承关系在使模式灵活的同时，也增加了复杂性。这都是使用模式时需要考虑的因素。切记:模式中的类是作为一个整体而存在，它们是紧密耦合的关系；模式描述了这些类之间的关系和约束因素，丰富设计词汇，使我们容易交流，但同时要清楚实现时是对这些类和这些交互关系的再现。
设计模式与封装变化
设计模式可以确保系统能以特定方式变化(这很大程度是一种预测)，从而帮助设计者避免重新设计系统。每一个设计模式允许系统结构的某个部分的变化独立于其他部分，这样产生的系统对于某一种特殊变化将更健壮。
下面阐述一些导致重新设计的一般原因，以及解决这些问题的常用设计模式：
1) 通过显式地指定一个类来创建对象。在创建对象时指定类名将使设计者受特定实现的约束, 而不是特定接口的约束。这会使未来的变化更复杂。要避免这种情况，应该间接地创建对象。
设计模式：Abstract Factory，Factory Method，Prototype。
2) 对特殊操作的依赖。 当设计者为请求指定一个特殊操作时，完成该请求的方式就固定了。避免把请求代码写死，可在编译时刻或运行时刻方便地改变响应请求的方法。
设计模式：Chain of Responsibility，Command。
3) 对硬件和软件平台的依赖。 外部的操作系统接口和应用编程接口(API)在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上，甚至都很难跟上本地平台的更新。所以设计系统时限制其平台相关性就很重要了。
设计模式：Abstract Factory，Bridge。
4) 对对象表示或实现的依赖。 知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。
设计模式：Abstract Factory，Bridge，Memento，Proxy
5) 算法依赖。 算法在开发和复用时常常被扩展、优化和替代。依赖于某个特定算法的对象在算法发生变化时不得不变化。因此有可能发生变化的算法应该被孤立起来。
设计模式：Builder，Iterator，Strategy，Template Method，Visitor
6) 紧耦合的类很难独立地被复用，因为它们是互相依赖的。紧耦合产生单块的系统，要改变或删掉一个类，必须理解和改变其他类。这样的系统是一个很难学习、移植和维护的密集体。
松散耦合提高了一个类本身被复用的可能性，并且系统更易于学习、移植、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性。
设计模式：Abstract Factory，Command，Facade，Mediator，Observer，Chain of Responsibility
7) 通过生成子类来扩充功能。 通常很难通过定义子类来定制对象。每一个新类都有固定的实现开销(初始化、终止处理等)。定义子类还需要对父类有深入的了解。如，重定义一个操作可能需要重定义其他操作。一个被重定义的操作可能需要调用继承下来的操作。并且子类方法会导致类爆炸，因为即使对于一个简单的扩充，也不得不引入许多新的子类。(本质: 继承应该仅仅封装一个变化点)
一般的对象组合技术和具体的委托技术，是继承之外组合对象行为的另一种灵活方法。新的功能可以通过以新的方式组合已有对象，而不是通过定义已存在类的子类的方式加到应用中去。另一方面，过多使用对象组合会使设计难于理解。许多设计模式产生的设计中，设计者可定义一个子类，且将它的实例和已存在实例进行组合来引入定制的功能。
设计模式：Bridge，Chain of Responsibility，Composite，Decorator，Observer，Strategy
8) 不能方便地对类进行修改。 有时设计者不得不改变一个难以修改的类。也许你需要源代码而又没有(对于商业类库就有这种情况)，或者可能对类的任何改变会要求修改许多已存在的其他子类。设计模式提供在这些情况下对类进行修改的方法。
设计模式：Adapter，Decorator，Visitor
设计模式与其封装的变化点
|
| 设计模式 | 变化点 |
| 创建型 | Abstract Factory | 产品对象家族 |
| Builder | 组合创建组合(复杂) 对象 | |
| Factory Method | 被实例化的子类(相关类) | |
| Prototype | 被实例化的类 | |
| Singleton | 一个类的唯一实例 | |
| Object Factory | 被实例化的类，Factory Method的变种 | |
| Object Pool | 对象管理和重用，Factory Method的变种 | |
| Creation Method | 类的构造函数，Factory Method的变种 | |
| 结构型 | Adapter | 对象的接口(可变API) |
| Bridge | 对象实现(实现逻辑) | |
| Composite | 对象的结构和组成 | |
| Decorator | 对象的职责(职责组合) | |
| Façade | 子系统的接口(子系统的变化) | |
| Flyweight | 对象的存储 | |
| Proxy | 对象的访问和对象的位置 | |
| 行为型 | Chain of Responsibility | 满足某个请求的对象(请求的实际处理对象) |
| Command | 何时、如何实现某个请求 | |
| Interpreter | 一个语言的文法和解释 | |
| Iterator | 如何遍历、访问一个聚合的各元素 | |
| Mediator | 对象间的交互逻辑 | |
| Memento | 对象信息的存储管理 | |
| Observer | 对象间的依赖和通讯 | |
| State | 对象状态 | |
| Strategy | 算法 | |
| Template Method | 算法某些步骤 | |
| Visitor | 作用于对象上的操作 |