SOLID架构设计原则

设计原则概述

通常来说，要想构建—个好的软件系统，应该从写整洁的代码开始做起。毕竟，如果建筑所使用的砖头质量不佳，那么架构所能起到的作用也会很有限。反之亦然，如果建筑的架构设计不佳，那么其所用的砖头质量再好也没有用。这就是SOLID设计原则所要解决的问题。

SOLID原则的主要作用就是告诉我们如何将数据和函数组织成为类，以及如何将这些类链接起来成为程序。请注意，这里虽然用到了“类”这个词，但是并不意味着我们将要讨论的这些设计原则仅仅适用于面向对象编程。这里的类仅仅代表了一种数据和函数的分组，每个软件系统都会有自己的分类系统，不管它们各自是不是将其称为“类”，事实上都是SOLID原则的适用领域。

一般情况下，我们为软件构建中层结构的主要目标如下：

• 使软件可容忍被改动
• 使软件更容易被理解
• 构建可在多个软件系统中复用的组件

我们在这里之所以会使用“中层”这个词，是因为这些设计原则主要适用于那些进行模块级编程的程序员。SO凵D原则应该直接紧贴于具体的代码逻辑之上，这些原则是用来帮助我们定义软件架构中的组件和模块的。

当然了，正如用好砖也会盖歪楼一样，采用设计良好的中层组件并不能保证系统的整体架构运作良好。正因为如此，我们在讲完SOLID原则之后，还会再继续针对组件的设计原则进行更进一步的讨论，将其推进到高级软件架构部分。

SOLID原则的历史已经很悠久了，早在20世纪80年代末期，我在 USENET新闻组（该新闻组在当时就相当于今天的 Facebook）上和其他人辩论软件设计理念的时候，该设计原则就已经开始逐渐成型了。随着时间的推移，其中有一些原则得到了修改，有一些则被抛弃了，还有一些被合并了，另外也增加了一些。它们的最终形态是在2000年左右形成的，只不过当时采用的是另外一个展现顺序。

2004年前后， Michael feathers的一封电子邮件提醒我:如果重新排列这些设计原则，那么它们的首字母可以排列成SOLID——这就是SOLID原则诞生的故事。

在这一部分中，我们会逐章地详细讨论每个设计原则，下面先来做一个简单摘要。

SRP:单一职责原则。

该设计原则是基于康威定律（ Conway‘s Law）的一个推论——软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构。这样，每个软件模块都有且只有一个需要被改变的理由。

OCP:开闭原则。

该设计原则是由 Bertrand Meyer在20世纪80年代大力推广的，其核心要素是:如果软件系统想要更容易被改变，那么其设计就必须允许新增代码来修改系统行为，而非只能靠修改原来的代码。

LSP:里氏替换原则。

该设计原则是 Barbara liskov在1988年提出的著名的子类型定义。简单来说，这项原则的意思是如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换。

ISP:接口隔离原则。

这项设计原则主要告诫软件设计师应该在设计中避免不必要的依赖。

DIP:依赖反转原则。

该设计原则指出高层策略性的代码不应该依赖实现底层细节的代码，恰恰相反，那些实现底层细节的代码应该依赖高层策略性的代码。

这些年来，这些设计原则在很多不同的出版物中都有过详细描述。在接下来的章节中，我们将会主要关注这些原则在软件架构上的意义，而不再重复其细节信息。如果你对这些原则并不是特别了解，那么我建议你先通过脚注中的文档熟悉一下它们，否则接下来的章节可能有点难以理解。

SRP:单一职责原则

SRP是SOLID五大设计原则中最容易被误解的一。也许是名字的原因，很多程序员根据SRP这个名字想当然地认为这个原则就是指:每个模块都应该只做一件事。

没错，后者的确也是一个设计原则，即确保一个函数只完成一个功能。我们在将大型函数重构成小函数时经常会用到这个原则，但这只是一个面向底层实现细节的设计原则，并不是SRP的全部。

在历史上，我们曾经这样描述SRP这一设计原则：

任何一个软件模块都应该有且仅有一个被修改的原因。

在现实环境中，软件系统为了满足用户和所有者的要求，必然要经常做出这样那样的修改。而该系统的用户或者所有者就是该设计原则中所指的“被修改的原因”。所以，我们也可以这样描述SRP：

任何一个软件模块都应该只对一个用户（User）或系统利益相关者（ Stakeholder）负责。

不过，这里的“用户”和“系统利益相关者”在用词上也并不完全准确，它们很有可能指的是一个或多个用户和利益相关者，只要这些人希望对系统进行的变更是相似的，就可以归为一类——一个或多有共同需求的人。在这里，我们将其称为行为者（ actor）。

所以，对于SRP的最终描述就变成了：

任何一个软件模块都应该只对某一类行为者负责。

那么，上文中提刭的“软件模块”究竟又是在指什么呢？大部分情况下，其最简单的定义就是指一个源代码文件。然而，有些编程语言和编程环境并不是用源代码文件来存储程序的。在这些情况下，“软件模块”指的就是一组紧密相关的函数和数据结构。

在这里，“相关”这个词实际上就隐含了SRP这一原则。代码与数据就是靠着与某一类行为者的相关性被组合在一起的。

或许，理解这个设计原则最好的办法就是让大家来看一些反面案例。

反面案例1:重复的假象。

这是我最喜欢举的一个例子:某个工资管理程序中的 Employee类有三个函数 calculate Pay（）、reportHours（）和save（）。

如你所见，这个类的三个函数分别对应的是三类非常不同的行为者，违反了SRP设计原则。

calculatePay（）函数是由财务部门制定的，他们负责向CFO汇报。

reportHours（）函数是由人力资源部门制定并使用的，他们负责向COO汇报。

save（）函数是由DBA制定的，他们负责向CTO汇报。

这三个函数被放在同一个源代码文件，即同一个Employee类中，程序员这样做实际上就等于使三类行为者的行为耦合在了一起，这有可能会导致CFO团队的命令影响到COO团队所依赖的功能。

例如， calculatePay（）函数和 reportHours（）函数使用同样的逻辑来计算正常工作时数。程序员为了避免重复编码，通常会将该算法单独实现为个名为 regularHoursÿ