我对面向对象的6大设计原则的理解
程序员都知道编程有 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 种方案可以选择：
- 你重新开发一个新的 API 供客户调用。
- 建议客户利用现成的 SDK 扩展一个新的 API 自己解决问题。
说具体点，比如客户临时提出一个美颜的需求。
你评估了自己的 SDK 里面发现有人脸检测 API，有区域调色 API,有图像锐化 API,这个很轻易组装一个美颜的 API,所以你不需要从头开发出来。
这就体现了开闭原则，开对于于需求，对需求的变动保持开发，闭对于已有的成果，不轻易破坏原有代码的稳定性。
3. 里氏替换原则（Liskov Substitution Principle）
描述：所有引用基类的地方必须能透明地引用其子类。
理解：举个简单的例子，假如一个会议的参会要求是，你必须是农民。那么，可以定义农民为基类。所以，只要是集成了农民的子类比如花农、果农、种植水稻的农民都可以参加这个会议。
4. 迪米特法则（Law of Demeter）
描述：只和你的直接朋友对话，不和陌生人对话。
理解：这一个原则很具人生哲学代表性。本质还是为了解耦，避免不必要的耦合，降低复杂度，并且提高安全性。我们熟悉的谍战片都是这个模式，卧底只和一个上线对话。
5. 接口隔离原则（Interface Segregation Principle）
描述：客户端不应该依赖于它不需要的接口，不同的类之间的关系应该建立在最少的接口基础上。
理解：这其实就是解耦合的的具体体现。举个生动的例子。
我认为接口应该是一种承诺，或者是协议。
甲方给乙方一系列接口，就算给了承诺。
但甲方多变，乙方做好心理打算就好了，有些话听听就好了，提取最有用的信息，完成自己的任务，万一需求变动，再改也方便，如果一开始就整那些有的没的的东西，甲方再改动需求时，影响的范围会更大。
另外有种情况是，甲方有好几个乙方，不同的乙方需要一起协同。
这要求不同乙方之间约定好对话窗口，目的也是降低耦合度，保护自己尽可能少受需求变动之苦。
6. 依赖倒置原则（Dependence Inversion Principle）
描述：上层不应该依赖于底层，底层应该依赖于上层。抽象不应该依赖于细节，细节应该依赖于抽象。
理解：听起来挺拗口的，其实也好理解。
)
我是一个人，我从广州去深圳，我说我依赖汽车、火车、自行车，这站在软件角度都不对的，因为我太依赖于细节了，这样面对不了未来的需求变化，所以应该有更好的解决方法。
正确的应该是，我依赖于交通工具这个接口或者是抽象类。
那么，我坐飞机、自行车、汽车、火车都满足情况，未来可能还有地铁、轻轨等等，这就是面向未来的编程方式。
也是底层依赖上层，细节依赖抽象的意思。
依赖倒置的意思是，本来 Person 依赖于具体的实现类，后来引进了交通工具这个抽象类，自行车、汽车、火车这些交通工具反而要依赖于接口，这个从被依赖到依赖别人的改变就看做是依赖关系的倒置，所以叫依赖倒置。
最后，拥抱变化不是一句空话，你得反映到代码中来。