什么是设计模式？

• 每一种模式都描述了一种问题的通用解决方案。这样问题在我们的环境中，不停地出现。

• 可重复使用的解决方案。

一个设计模式分四个部分：

• 模式名称：由少量的字组成的名称，有助于我们表达我们的设计。

• 待解问题：描述了合适需要运用这种模式，以及运用模式的环境（上下文）。

• 解决方案：描述了组成设计的元素（类和对象）、他们的关系、职责以及合作。但这种解决方案是抽象的，它不代表具体的实现。

• 结论：运用这种方案带来的利与弊。主要是指它对系统的弹性、扩展性和可移植性的影响。

针对的问题

使用场景

为了构建健壮性的系统，设计应该支持变化。而设计模式可以确保系统能以特定方式变化，这种特定的变化就是以“封装变化”来实现的。设计模式抽象的层次主要就是在这，让需求或外在的干扰的部分，排除在外。从而一不变应万变，不需要或很少的重新设计系统，也避免带来的重新测试上线带来的风险。

以下几种使用场景：

1） 通过显示地指定一个类来创建对象——考虑接口的约束，间接的创建对象，可用到的模式：

Factory Method（工厂方法）、 Abstract Factory（抽象工厂）、 Prototype（原型）

2）对特殊操作的依赖——在请求方式固定的情况下，在编译时刻或运行时候方便地改变其请求的方法，可用到的模式：

Chain of Responsibility（责任链）、 Command（命令）

3）对硬件和软件平台的依赖——由于外部的接口和应用 API 在不同平台上不同，可用到的模式：

Abstract Factory（抽象工厂）、Bridge（桥接）

4）对对象表示或实现的依赖——知道对象发生变化时也需要变化，对客户隐藏某些信息阻止连锁变化，可用到的模式：Abstract Factory（抽象工厂）、Bridge（桥接）、Memento（备忘录）、Proxy（代理）

5）算法依赖—— 依赖于某个特定算法的对象在发生变化时不得不变化，可能发生变化的算法应该被孤立起来，可用到的模式：

Bridge（桥接）、Mediator（中介者）、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 Class/Object（适配器）、Decorator（装饰）、Visitor（访问者）

设计模式之间的联系

设计模式需要多揣摩，多实践，无论在 jdk 的 API 中还是在 spring 等框架中都得到了广泛的应用，通过后缀名即可搜到很多，比比皆是，在这不一一列举。勤翻翻看看，会对自己的认识有帮助。