程序员都知道编程有 3 大类：面向过程、面向对象、面向函数。面向对象是被讨论的最多的，个人认为，这是因为 Java 之类的编程语言有强大的用户基础，本质还是因为比较符合人的直觉。

说到面向对象，大家可能就会很快想到了 23 种设计模式，可只有少部分人会想到面向对象的 6 大原则，所以本文我分享一下我对于 6 大原则的看法。

6 大原则是内功心法，23 种设计模式是武术套路，它们的本质是为了更好地面对需求的变化。

很多人对于设计模式背诵的滚瓜烂熟，但是却没有办法评价自己的代码质量，尤其是根据自己的想法整了一大堆设计模式之后，很难分辨自己是规范编程还是过度设计。

其实，设计模式是立足于 6 大设计原则上的。

6 大设计原则对应 6 个规则，取首字母缩写就是 SOLID 。

1.  单一职责原则 (Single Responsibility Principle)

描述：一个类只有一个引起修改的原因。

理解：我们都知道要软件开发要解耦合，解耦合的理想状态就是一个类只负责一个功能。

软件开发要做好拥抱变化的准备。

比如，1 个月前，你做了一个类，负责用户模块。

后来需求变动，登录增加了微信账号登录，你得改你的用户模块。

后来需求变动，注册增加了手机动态码验证，你的修改你的用户模块。

后来需求变动，登录增加了github 登录，你的修改你的用户模块。

后来需求变动，登录增加了weibo 登录验证，你得修改你的用户模块。

后来需求变动，... 你已经麻木了。

你会发现，你的用户模块越来越臃肿了。

但是，如果你一早就实现 2 个类，一个负责登录，一个负责注册。

那么登录需求的变化不会影响注册的代码，反之亦然。

虽然，代码没有减少多少，但你可以明确感受到职责分明，所以开发会更轻松一点。

2. 开闭原则 (Single Responsibility Principle)

描述：一个软件实体，应该对扩展开放，对修改关闭。

理解：很多人可能对这个概念感到有些玄乎，其实很好理解的。

假设你是乙方，你给甲方的交付物是一个 SDK,有一天客户想要增加一个功能，现在有 2 种方案可以选择：

1. 你重新开发一个新的 API 供客户调用。

2. 建议客户利用现成的 SDK 扩展一个新的 API 自己解决问题。

说具体点，比如客户临时提出一个美颜的需求。

你评估了自己的 SDK 里面发现有人脸检测 API，有区域调色 API,有图像锐化 API,这个很轻易组装一个美颜的 API,所以你不需要从头开发出来。

这就体现了开闭原则，开对于于需求，对需求的变动保持开发，闭对于已有的成果，不轻易破坏原有代码的稳定性。

3. 里氏替换原则(Liskov Substitution Principle)

描述：所有引用基类的地方必须能透明地引用其子类。

理解：举个简单的例子，假如一个会议的参会要求是，你必须是农民。那么，可以定义农民为基类。所以，只要是集成了农民的子类比如花农、果农、种植水稻的农民都可以参加这个会议。

4. 迪米特法则(Law of Demeter)

描述：只和你的直接朋友对话，不和陌生人对话。

理解：这一个原则很具人生哲学代表性。本质还是为了解耦，避免不必要的耦合，降低复杂度，并且提高安全性。我们熟悉的谍战片都是这个模式，卧底只和一个上线对话。

5. 接口隔离原则(Interface Segregation Principle)

描述：客户端不应该依赖于它不需要的接口，不同的类之间的关系应该建立在最少的接口基础上。

理解：这其实就是解耦合的的具体体现。举个生动的例子。

我认为接口应该是一种承诺，或者是协议。

甲方给乙方一系列接口，就算给了承诺。

但甲方多变，乙方做好心理打算就好了，有些话听听就好了，提取最有用的信息，完成自己的任务，万一需求变动，再改也方便，如果一开始就整那些有的没的的东西，甲方再改动需求时，影响的范围会更大。

另外有种情况是，甲方有好几个乙方，不同的乙方需要一起协同。

这要求不同乙方之间约定好对话窗口，目的也是降低耦合度，保护自己尽可能少受需求变动之苦。

6. 依赖倒置原则(Dependence Inversion Principle)

描述：上层不应该依赖于底层，底层应该依赖于上层。抽象不应该依赖于细节，细节应该依赖于抽象。

理解：听起来挺拗口的，其实也好理解。

)

我是一个人，我从广州去深圳，我说我依赖汽车、火车、自行车，这站在软件角度都不对的。

正确的应该是，我依赖于交通工具这个接口或者是抽象类。

那么，我坐飞机、自行车、汽车、火车都满足情况，未来可能还有地铁、轻轨等等，这就是面向未来的编程方式。

也是底层依赖上层，细节依赖抽象的意思。

依赖倒置的意思是，本来 Person 依赖于具体的实现类，后来引进了交通工具这个抽象类，自行车、汽车、火车这些交通工具反而要依赖于接口，这个从被依赖到依赖别人的改变就看做是依赖关系的倒置，所以叫依赖倒置。

最后，拥抱需求不是一句空话，需要在代码中反映。

近期技术文章：

工作多年，我对架构的一些理解

程序员能轻易干好其他专业吗？

聊聊线程和进程