再谈 SOLID 原则，Why SOLID?

Why SOLID?

在前一篇文章中介绍 SOLID 对一个工程师的影响，这里再稍微补充一下为什么软体开发会需要 SOLID 原则？

软体複杂的本质

专案经常会历经「商业逻辑调整」和「快速且多变的需求」，这都不是开发环节所能控制的，但是一个专案会「遇到困难」常常是因为 糟糕的程式设计 和其他技术层面导致。

其中 糟糕的程式设计 又可分成三大因素：

程式码变更Bug 修复複杂度控制

在添加功能前应该 阅读代码并细心设计，但实际上更常发生的是，开发者选择直接在程式码上面堆叠新的程式码。新旧版本 和 意图不同 的程式码错综複杂之下，会让专案难以在不引发连锁反应的情况下增加功能。最后新的功能引入 Bug，从而导致另一个 Bug，然后一个接着一个，这样的事情不断发生。

在 没有做过可扩展性设计的程式码 上进行扩展功能，常常是火上加油！
那为什么不把程式「设计」成可扩展就好了呢？

开发者知识普遍不足

一个充满外行人的产业

开发者们来自不同的背景，且有大量不同的方式去解决问题，但是一个开发者应该具备什么样的知识体系，却没有一个广泛的共识。

更不幸的是，许多开发者在学校里面学到的知识是过时的，学校提供的程式设计课程并未给学生做好準备。这些课程通常只关注程式语言的功能，但是 ...

掌握一门程式语言并不能使你成为软体开发者，正如掌握一门自然语言并不能使你成为作家

学校所教的知识，并不是大部分软体开发者的工作内容。开发者也许能编写一个可运行的程式码，但若要回头去扩展程式码却常常是艰难且冒险的。

软体开发过程中，开发者需要做出无数个选择，加上每个开发者用不同的方法解决问题，助长了难以维护、难以扩展的程式码。最终让 系统设计的思想沟通 变得困难。

工程师必须花费大量时间阅读程式码。

不论是开发者还是管理者都需要对 软体複杂的本质 做管理。为了编写出更容易应对变化的程式码，我们必须填补基础认知方面的空白。

导入设计原则

若有一些原则可以指导工程师在 一定的情况下理解每个选择的所得所失 并做出最佳权衡，则可以统一工程师解决问题的方法，降低 系统设计思想沟通 的困难度。

Uncle Bob 花费多年整理了许多开发人员、研究人员的思想和着作结晶，提出了 5 个设计原则：

单一职责原则（The Single Responsibility Principle, 简称 SRP)开放-封闭原则 (The Open-Close Principle, 简称 OCP)里氏替换原则 (The Liskov Substitution Principle, 简称 LSP)依赖倒置原则 (The Dependency Inversion Principle, 简称 DIP)接口隔离原则 (Interface Segregation Principle, 简称 ISP)

SOLID 原则目的是让程式码在面对改变时，能有一套策略来应对。

SOLID 原则指导开发者们该 如何将函式和资料结构安排到类别中，以及这些 类别该如何互相关联。

遵循 SOLID 原则的程式码具有以下特性：

能够容忍变化容易扩展新逻辑容易理解容易複用

虽然 SOLID 原则是 物件导向 的设计原则，但事实上这些原则与思维一直存在软体工程中。因此 SOLID 原则的思维可以延伸套用至非物件导向语言、系统架构等等领域。

顺带一提，SOLID 原则并没有顺序关係，单纯是 Michael Feathers(1 发了电子邮件告诉 Uncle Bob 可以用 SOLID 这个词彙将 5 个原则串起来变成口诀方便记忆。
所以在学习 SOLID 原则的过程中，可以不用按照顺序学习。

备注：

Michael Feathers 是 Working Effectively with Legacy Code 的作者，也是一本开发者必读经典书籍。

此文章也会同步到：我的部落格

系列文章

浅谈物件导向 SOLID 原则对工程师的好处与如何影响能力再谈 SOLID 原则，Why SOLID?物件导向设计原则：单一职责原则，定义、解析与实践物件导向设计原则：开放封闭原则，定义、解析与实践

---