设计模式与六大原则

大家好，欢迎来到IT知识分享网。

1、设计模式6大原则

软件编程的总原则：高内聚、低耦合。

1.1 单一职责原则（Single Responsibility Principle，简称SRP ）

There should never be more than one reason for a class to change.
定义：不要存在多于一个导致类变更的原因，即一个类只负责一项职责。
优点：
1、可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
2、提高类的可读性，提高系统的可维护性；
3、变更引起的风险降低。变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
特别说明，单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

1.2 开放封闭原则（Open Close Principle,简称OCP）

Software entities like classes,modules and functions should be open for extension but closed for modifications.
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

开闭原则由Bertrand Meyer于1988年提出，是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。开闭原则可能是设计模式六项原则中定义最模糊的一个了，它只告诉我们对扩展开放，对修改关闭，可是具体做法并没有明确的告诉我们。

其实，我们遵循设计模式的其他5大原则，以及使用23种设计模式的目的就是遵循开闭原则。也就是说，只要我们对其余5项原则遵守的好了，设计出的软件自然是符合开闭原则的。这个开闭原则更像是另外五项原则遵守程度的“平均得分”，这5项原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；如果这5项原则遵守的不好，则说明开闭原则遵守的不好。

其实笔者认为，开闭原则的意思是：$用抽象构建框架，用实现扩展细节。$
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

1.3 里氏替换原则（Liskov Substitution Principle,简称LSP）

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
这项原则最早是在1988年，由麻省理工学院的一位女科学家（Barbara Liskov）提出来的。
定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
定义2：所有引用基类的地方必须能透明地使用其子类的对象。

1.4 依赖倒置原则（Dependence Inversion Principle,简称DIP）

High level modules should not depends upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

依赖倒置原则的核心思想是面向接口编程。遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险，也给多人并行开发带来了极大的便利。

传递依赖关系有三种方式：接口传递、构造方法传递、setter方法传递。相信用过Spring框架的，对依赖的传递方式一定不会陌生。

1.5 接口隔离原则（Interface Segregation Principle,简称ISP）

The dependency of one class to another one should depend on the smallest possible interface.
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
具体含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。

1.6 迪米特原则（或最少知道原则，Law of Demeter,简称LoD）

Only talk to you immediate friends.
定义：一个对象应该对其他对象保持最少的了解。即一个类对自己依赖的类知道的越少越好。
更简单的定义：只与直接的朋友通信。
每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，如依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

前五个原则（单一职责、开放封闭、里氏替换、接口隔离、依赖倒置）被Bob大叔在21世纪早期定义为SOLID（即稳定的，由首字母合成而来）原则。作为面向对象编程的五个基本原则，当这些原则被一起使用时，它们使得一个软件系统更清晰、简单，最大程度地拥抱变化。

最后说明一下如何去遵守这六个原则。对这六个原则的遵守并不是是和否的问题，而是多和少的问题，也就是说，我们一般不会说有没有遵守，而是说遵守程度的多少。任何事都是过犹不及，设计模式的六个设计原则也是一样，制定这六个原则的目的并不是要我们刻板的遵守他们，而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内，就算是良好的设计。

参考资料：设计模式六大原则

如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

7种原则总结：
开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；
里氏替换原则告诉我们不要破坏继承体系；
依赖倒置原则告诉我们要面向接口编程；
单一职责原则告诉我们实现类要职责单一；
接口隔离原则告诉我们在设计接口的时候要精简单一；
迪米特法则告诉我们要降低耦合度；
合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。

2、GoF的23种设计模式的分类和功能

2.1 设计模式分类

2.1.1 根据目的来分

2.1.2 根据作用范围来分

创建型模式
创建范例全部是关于如何创建实例的。这组范例可以被划分为两组：类创建范例及对象创建范例。类创建实例在实例化过程中有效的使用类之间的继承关系，对象创建范例则使用代理来完成其任务。
1、工厂方法 (Factory Method pattern，包括简单工厂模式和工厂方法模式)
2、抽象工厂 (Abstract Factory)
3、构造器 (建造者，Builder Pattern)
4、原型 (Prototype pattern)
5、单例 (Singleton pattern)

结构型模式
这组范例都是关于类及对象复合关系的。
1、适配器 (Adapter pattern)
2、桥接 (Bridge pattern)
3、组合 (Composite pattern)
4、装饰 (Decorator pattern)
5、外观 (门面，Facade pattern)
6、享元 (Flyweight pattern)
7、代理 (Proxy pattern)

行为型模式
这组范例都是关于对象之间如何通讯的。
1、责任链 (职责链，Chain-of-responsibility pattern)
2、命令 (Command pattern)
3、解释器 (Interpreter pattern)
4、迭代器 (Iterator pattern)
5、中介者 (调停者，Mediator pattern)
6、备忘录 (Memento pattern)
7、观察者 (Observer pattern)
8、状态 (State pattern)
9、策略 (Strategy pattern)
10、模板方法 (Template method pattern)
11、访问者 (Visitor)

2.2 设计模式的功能

必须指出，这 23 种设计模式不是孤立存在的，很多模式之间存在一定的关联关系，在大的系统开发中常常同时使用多种设计模式，希望读者认真学好它们。

参考资料：23种设计模式全面解析