写了这么多年代码，你真的了解SOLID吗？

尽管大家都认为SOLID是非常重要的设计原则，并且对每一条原则都耳熟能详，但我发现大部分开发者并没有真正理解。要获得最大收益，就必须理解它们之间的关系，并综合应用所有这些原则。只有把SOLID作为一个整体，才可能构建出坚实(Solid)的软件。遗憾的是，我们看到的书籍和文章都在罗列每个原则，没有把它们作为一个整体来看，甚至提出SOLID原则的Bob大叔也没能讲透彻。因此我尝试介绍一下我的理解。

先抛出我的观点: 单一职责是所有设计原则的基础，开闭原则是设计的终极目标。里氏替换原则强调的是子类替换父类后程序运行时的正确性，它用来帮助实现开闭原则。而接口隔离原则用来帮助实现里氏替换原则，同时它也体现了单一职责。依赖倒置原则是过程式编程与OO编程的分水岭，同时它也被用来指导接口隔离原则。关系如下图：

单一职责原则(Single Responsibility Principle, SRP)

单一职责是最容易理解的设计原则，但也是被违反得最多的设计原则之一。

要真正理解并正确运用单一职责原则，并没有那么容易。单一职责就跟“盐少许”一样，不好把握。Robert C. Martin(又名“Bob大叔”)把职责定义为变化原因，将单一职责描述为 ”A class should have only one reason to change." 也就是说，如果有多种变化原因导致一个类要修改，那么这个类就违反了单一职责原则。那么问题来了，什么是“变化原因”呢?

利益相关者角色是一个重要的变化原因，不同的角色会有不同的需求，从而产生不同的变化原因。作为居民，家用的电线是普通的220V电线，而对电网建设者，使用的是高压电线。用一个Wire类同时服务于两类角色，通常意味着坏味道。

变更频率是另一个值得考虑的变化原因。即使对同一类角色，需求变更的频率也会存在差异。最典型的例子是业务处理的需求比较稳定，而业务展示的需求更容易发生变更，毕竟人总是喜新厌旧的。因此这两类需求通常要在不同的类中实现。

单一职责原则某种程度上说是在分离关注点。分离不同角色的关注点，分离不同时间的关注点。

在实践中，怎么运用单一职责原则呢?什么时候要拆分，什么时候要合并?我们看看新厨师在学炒菜时，是如何掌握“盐少许”的。他会不断地品尝，直到味道刚好为止。写代码也一样，你需要识别需求变化的信号，不断“品尝”你的代码，当“味道”不够好时，持续重构，直到“味道”刚刚好。

开闭原则(Open-closed Principle)

开闭原则指软件实体(类、模块等)应当对扩展开放，对修改闭合。这听起来似乎很不合理，不能修改，只能扩展?那我怎么写代码?

我们先看看为什么要有开闭原则。假设你是一名成功的开源类库作者，很多开发者使用你的类库。如果某天你要扩展功能，只能通过修改某些代码完成，结果导致类库的使用者都需要修改代码。更可怕的是，他们被迫修改了代码后，又可能造成别的依赖者也被迫修改代码。这种场景绝对是一场灾难。

如果你的设计是满足开闭原则的，那就完全是另一种场景。你可以通过扩展，而不是修改来改变软件的行为，将对依赖方的影响降到最低。

这不正是设计的终极目标吗?解耦、高内聚、低耦合等等设计原则最终不都是为了这个目标吗?畅想一下，类、模块、服务都不需要修改，而是通过扩展就能够改变其行为。就像计算机一样，组件可以轻松扩展。硬盘太小?直接换个大的，显示器不够大的?来个8K的怎么样?

什么时候应该应用开闭原则，怎么做到呢?没有人能够在一开始就识别出所有扩展点，也不可能在所有地方都预留出扩展点，这么做的成本是不可接受的。因此一定是由需求变化驱动。如果你有领域专家的支持，他可以帮你识别出变化点。否则，你应该在变化发生时来做决策，因为在没有任何依据时做过多预先设计违反了Yagni。

实现开闭原则的关键是抽象。在Bertrand Meyer提出开闭原则的年代(上世纪80年代)，在类库中增加属性或方法，都不可避免地要修改依赖此类库的代码。这显然导致软件很难维护，因此他强调的是要允许通过继承来扩展类。随着技术发展，我们有了更多的方法来实现开闭原则，包括接口、抽象类、策略模式等。