设计模式之概述

1 概述

设计模式总体来说分为三大类：

1. 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

2. 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

3. 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

2 设计模式的六大原则

1. 单一职责原则

不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责，也就是只有一个原因导致一个类变化。

单一职责的优点如下：

可以降低类的复杂度，一个类只负责一项职责；提高类的可读性，提高系统的可维护性；变更引起的风险降低，当修改一个功能时，可以显著降低对其他功能的影响。

1. 里氏代换原则（Liskov Substitution Principle）

里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。

LSP 是继承复用的基石，只有当衍生类替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。它包含以下4层含义：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。子类中可以增加自己特有的方法。当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

1. 依赖倒转原则（Dependence Inversion Principle）

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

传递依赖关系有三种方式:接口传递;构造方法传递;setter方法传递。满足依赖导致一般需要做到以下三点

低层模块尽量都要有抽象类或接口，或者两者都有。变量的声明类型尽量是抽象类或接口。使用继承时遵循里氏替换原则。

1. 接口隔离原则（Interface Segregation Principle）

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

采用接口隔离原则对接口进行约束时，要注意以下几点：

接口尽量小，但是要有限度。接口细化可提高灵活性,但若是过小，则会造成接口数量过多，使设计复杂化。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

1. 迪米特法则（最少知道原则）（Demeter Principle）

一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

1. 开闭原则（Open Close Principle）

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。