设计模式之概述

参考资料：菜鸟教程之设计模式

设计模式概述

设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
设计模式是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。

使用设计模式的目的

为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。 设计模式使代码编写真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

提出者

设计模式是由GOF(四人帮，Gang of Four)提出的。
在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。
四位作者合称 GOF（四人帮，全拼 Gang of Four）。他们所提出的设计模式主要是基于以下的面向对象设计原则：

• 对接口编程而不是对实现编程（依赖倒置原则）
• 优先使用对象组合而不是继承（合成复用原则）

设计模式的使用

设计模式在软件开发中的两个主要用途。

开发人员的共同平台

设计模式提供了一个标准的术语系统，且具体到特定的情景。例如，单例设计模式意味着使用单个对象，这样所有熟悉单例设计模式的开发人员都能使用单个对象，并且可以通过这种方式告诉对方，程序使用的是单例模式。

最佳的实践

设计模式已经经历了很长一段时间的发展，它们提供了软件开发过程中面临的一般问题的最佳解决方案。学习这些模式有助于经验不足的开发人员通过一种简单快捷的方式来学习软件设计。

设计模式的类型

根据设计模式的参考书Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 中所提到的，总共有23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。

下面用一个图片来整体描述一下设计模式之间的关系：

设计模式之间的关系.png

设计原则

S.O.L.I.D

1、单一职责原则（SRP：Single Responsibility Principle）

修改一个类的原因应该只有一个。

所谓类变化的原因是指类的职责。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。换句话说就是让一个类只负责一件事，当这个类需要做过多事情的时候，就需要分解这个类。
因为如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱这个类完成其它职责的能力。这种耦合会导致脆弱的设计，此原则的核心就是解耦和增强内聚性。

2、开闭原则（OCP：Open Close Principle）

类应该对扩展开放，对修改关闭。

扩展就是添加新功能的意思，因此该原则要求在添加新功能时不需要修改代码。
符合开闭原则最典型的设计模式是装饰器模式，它可以动态地将责任附加到对象上，而不用去修改类的代码。

3、里氏代换原则（LSP：Liskov Substitution Principle）

子类对象必须能够替换掉所有父类对象。

里氏代换原则是面向对象设计的基本原则之一。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。继承是一种 IS-A 关系，子类需要能够当成父类来使用，并且需要比父类更特殊。如果不满足这个原则，那么各个子类的行为上就会有很大差异，增加继承体系的复杂度。

4、接口隔离原则（ISP：Interface Segregation Principle）

使用多个专门的接口比使用单一的总接口要好。

它还有另外一个意思是：一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户仅需知道与之相关的接口即可。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

5、依赖倒置原则（DIP：Dependence Inversion Principle）

高层模块不应该依赖于低层模块，二者都应该依赖于抽象；
抽象不应该依赖于细节，细节应该依赖于抽象。

高层模块包含一个应用程序中重要的策略选择和业务模块，如果高层模块依赖于低层模块，那么低层模块的改动就会直接影响到高层模块，从而迫使高层模块也需要改动。程序要依赖于抽象接口，不要依赖于具体实现。

依赖于抽象意味着：

• 任何变量都不应该持有一个指向具体类的指针或者引用；
• 任何类都不应该从具体类派生；
• 任何方法都不应该覆写它的任何基类中的已经实现的方法。

其他常用原则

1、迪米特法则（LOD：The Law of Demeter）

又称最少知道原则，即“不要和陌生人说话”。是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

2、合成复用原则（CRP：Composite Reuse Principle）

尽量使用对象组合，而不是通过继承来达到复用的目的。

3、共同封闭原则（CCP：The Common Closure Principle）

一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。

4、稳定抽象原则（SAP：The Stable Abstractions Principle）

最稳定的包应该是最抽象的包，不稳定的包应该是具体的包，即包的抽象程度跟它的稳定性成正比。

5、稳定依赖原则（SDP：The Stable Dependencies Principle）

包之间的依赖关系都应该是稳定方向依赖的，包要依赖的包要比自己更具有稳定性。

下面三篇文章，通过Java实例来总结常用的设计模式：

设计模式之创建型模式
设计模式之结构型模式
设计模式之行为型模式