设计模式概念
设计模式（Design Pattern）是一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。使用设计模式是为了重用代码、使代码更易理解并保证代码的可靠性。
在面向对象编程语言中（例如Java），设计模式为我们提供了一套可复用的面向对象技术。
可复用面向对象软件系统一般划分为两大类：应用程序工具箱和框架（Framework）。
原理以及目标
Java设计模式贯彻的原理是：面向接口编程，而不是面向实现。其目标原则是：降低耦合，增强灵活性。
设计模式要素
模式名称（pattern name）
设计模式的名称简洁地描述了设计模式的问题、解决方案和效果。
问题（problem）
描述了应该在何时使用模式。
环境或初始环境（context或initial context）
环境说明模式的使用范围，也是模式应用之前的起始条件（也叫前提条件）。
解决方案（solution）
描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。
效果（consequences）
描述了模式应用的效果及使用模式应权衡的问题。
举例（examples）
使用一个或多个示意性的应用来说明特定的真实环境，以及模式是如何应用到环境中、改变环境并且给出当模式结束时的末态环境。
末态环境（resulting context）
模式应用到系统之后的状态。
推理
推理解释本模式的步骤、规则，以及此模式作为一个整体是如何以特定的方式解决模式的。
其他有关模式
描述在现有的系统中此模式与其他模式的静态和动态的关系。
已知的应用
已知的应用是在已有的系统模式中出现和应用的例子，有助于证明此模式确实是对一个重复发生的问题可行的解答。
设计模式分类
常用的设计模式可以概括为23种，按照特点可以将其分为三大类型
- 创建型
- 结构型
- 行为型
创建型
创建型模式是用来创建对象的模式，抽象了实例化的过程，帮助一个系统独立于其关联对象的创建、组合和表示方式。
所有创建型模式都有两个特点：
- 将系统所使用的具体类的信息封装起来；
- 隐藏类的实例是如何被创建和组织的。外界对于这些对象只知道它们共同的接口，而不清楚其具体的实现细节。 正因为以上两点，创建型模式在创建什么（what），由谁（who）来创建，以及何时（when）创建这些方面，都为软件设计者提供了尽可能大的灵活性。
创建型模式的作用：
- 封装创建逻辑，不仅仅是new一个对象那么简单。
- 封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。
常见的创建型设计模式模式：
单例模式（Singleton Pattern）
一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
工厂方法模式（Factory Pattern）
在工厂方法模式中，工厂类成为了抽象类，实际的创建工作将由其具体子类来完成。工厂方法的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中去，强调的是“单个对象”的变化。
抽象工厂模式（Abstract Factory）
抽象工厂是所有工厂模式中最为抽象和最具有一般性的一种形态。抽象工厂可以向客户提供一个接口，使得客户可以在不必指定产品具体类型的情况下，创建多个产品族中的产品对象，强调的是“系列对象”的变化。
建造者模式（Builder Pattern）
把构造对象实例的逻辑移到了类的外部，在类的外部定义了该类的构造逻辑。
原型模式（Prototype Pattern）
原型模式和工厂模式一样，同样对客户隐藏了对象创建工作，但与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过复制一个现有对象生成新对象。
结构型
结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象实现新的功能（对象结构型模式）。
常见的结构型设计模式
代理模式（Proxy）
为其他对象提供一种代理以控制对该对象的访问。
装饰模式（Decorator）
动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
适配器模式（Adapter）
将一个类的接口变换成客户端所期待的另一接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
组合模式（Composite）
将一个类的接口变换成客户端所期待的另一接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
桥梁模式（Bridge）
将一个类的接口变换成客户端所期待的另一接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
外观模式（Facade）
将一个类的接口变换成客户端所期待的另一接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
享元模式（Flyweight）
将一个类的接口变换成客户端所期待的另一接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
行为型
将一个类的接口变换成客户端所期待的另一接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
常见的行为型设计模式
模板方法模式（Template Method）
定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
命令模式（Command）
是一种高内聚的模式，将一个请求封装成一个对象，从而使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
责任链模式（Chain of Responsibility）
使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
策略模式（Strategy）
也叫政策模式，定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。
迭代器模式（Iterator）
提供一种方法访问一个容器对象中的各个元素，而又不需要暴露该对象的内部细节。
中介者模式（Mediator）
用一个中介对象封装一系列的对象交互，中介者使各对象不需要显式地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
观察者模式（Observer）
也叫发布订阅模式，定义对象间的一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。例如：EventBus
备忘录模式（Memento）
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
访问者模式（Visitor）
封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
状态模式（State）
当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类型，状态模式的核心是封装，状态的变更引起行为的变更。
解释器模式（Interpreter）
给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该文法表示来解释语言中的句子。
设计原则
单一职责原则
定义
一个类，应当只有一个引起它变化的原因；即一个类应该只有一个职责。
优点
- 降低类的复杂性；
- 提高类的可读性；
- 提高代码的可维护性和复用性；
- 降低因变更引起的风险。
单一职责原则的应用
Java EE 中的分层框架模式实际上体现了单一职责原则，它将整个系统按照职责的内聚性分为不同的层，层内的模块与类具有宏观的内聚性，所关注的事情是一致的。例如，业务逻辑层主要关注系统的业务逻辑与业务流，而数据访问层则只负责数据的持久化与访问。
里氏替换原则
定义
所有引用基类的地方必须能透明地使用其子类对象。清晰明确地说明只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道父类还是子类；但是反过来则不可以，有子类的地方，父类未必就能适应。
应用
里氏替换原则为良好的继承定义了一个规范。
- 子类必须完全实现父类的方法；
- 子类可以有自己的个性；
- 覆盖或实现父类的方法时输入参数可以被放大；
- 覆盖或实现父类的方法时输出结果可以被缩小。
**注意 ** 按照里氏替换原则，当多个类之间存在继承关系时，通常应该使用父类或接口来指向子类的对象（除非需要使用子类特有的方法），这更利于提高系统的可扩展性。
依赖倒置原则
定义
高层模块不应该依赖低层模块，两者都依赖其抽象，抽象不依赖细节， 细节应该依赖于抽象。
传统的过程性系统的设计办法倾向于高层次的模块依赖于低层次的模块；抽象层次依赖于具体层次。“倒置”原则将这个错误的依赖关系倒置了过来
依赖倒置原则在Java语言中的表现是
- 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生；
- 接口或抽象类不依赖于实现类；
- 实现类依赖于接口或抽象类；
接口隔离原则
定义
间的依赖关系应该建立在最小的接口上。
接口隔离原则的应用场合，只提供调用者需要的方法，屏蔽不需要的方法。
迪米特法则
定义
一个对象应当对其他对象尽可能少的了解。
开闭原则
定义
在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即应当可以在不必修改源代码的情况下改变这个模块的行为。
优点
- 提高复用性
- 提高可维护性
- 提高灵活性
- 易于测试
参考文档
设计模式：Java版 韩敬海主编
