1.引子
说起面向对象编程，我们都知道重要，且需要关注的这么一些事情。比如说设计思想、设计原则、设计模式。之所以说重要，一方面是面试需要，找工作的时候，总需要跟面试官聊上几句，这样显得大家都够专业；另外一方面则这是通往高级工程师，架构师的必备基本技能。
在这个系列中，前面我通过两篇文章给你分享了设计思想相关的一些内容，比如说编程范式，基于接口而非实现编程，高内聚低耦合。不知道你都还记得吗？这一篇我想接着给你分享设计原则相关的内容。
说起设计原则，你能先说一说都有哪些设计原则吗？经典的设计原则有
-
SOLID原则
-
KISS原则
-
YAGLI原则
-
DRY原则
-
LOD原则
设计原则的内容稍微有一些多，我们通过两篇文章来分享吧。这一篇我们一起先来看SOLID原则。你需要注意，SOLID并不只是一个设计原则，而是五个原则的统称，它们分别是：
-
SRP（ Single Responsibility Principle ）：单一职责原则
-
OCP（ Open Closed Principle ）：开闭原则
-
LSP（ Liskov Substitution Principle ）：里氏替换原则
-
ISP（ Interface Segregation Principle ）：接口隔离原则
-
DIP（ Dependence Inversion Principle ）：依赖倒置原则
2.SOLID原则
2.1.单一职责原则
单一职责原则，从字面意思上很好理解。它的原意是指一个模块，或者一个类只负责一个功能点。它告诉我们不要设计大而全的类，应该设计粒度小，功能职责单一的类。你看这就是单一职责原则，字面意思定义很好理解。
但是如果我们在实际项目中，用好单一职责原则却不是那么容易，表现在“单一”两个字不好量化，到底什么是单一呢？就好比大厨炒菜的时候说“盐放少许”，这里少许究竟是多少不好说。
那么下面我想给你分享，我在项目中衡量单一职责原则的两点参考心得
参考以上两点，我想大多数时候我们都可以评判一个模块，或者类的设计是否违背了单一职责原则。
2.2.开闭原则
开闭原则，从字面意思上也很好理解。它的原意是指软件实体（模块、类、方法），设计上应该对扩展开放，而对修改关闭。你看这就是开闭原则，字面意思定义很好理解。
但是同样的在实际项目中，开闭原则也是一个比较难把握分寸的原则。之所以这么说，是因为从不同的参考粒度来看,说不准是扩展了，还是修改了。从模块的粒度看是修改，从类的粒度看确认是添加。同样是盐放少许的问题，对吧。
下面我还是给你分享一下，我在项目中衡量开闭原则的两点参考心得
参考以上两点，我想大多数时候我们都可以评判一个模块，或者类的设计是否违背了开闭原则。
2.3.里氏替换原则
里氏替换原则，有点像面向对象编程的多态特性。它的原意是指一个软件系统中，父类出现的地方，子类可以无条件的替换父类，即里氏替换。
这里你需要注意无条件替换的内在含义，因为初一看我们很容易就把里氏替换当成简单多态了。事实上里氏替换是以多态为基础前提之上，提出了新的要求：里氏替换，子类替换父类，不能影响原有程序的逻辑，不能影响原有程序逻辑的正确性。这里的原有程序逻辑，我们可以理解为接口方法的输入、输出、异常处理逻辑等。因此很多时候，我们说里氏替换原则，还称为“Design by Contract”，基于契约的设计原则。
如果满足了该要求，那么我们说满足里氏替换原则。
2.4.接口隔离原则
接口隔离原则，这里的接口是，我们提倡基于接口而非实现编程中的接口，或者我们常说的API接口。它的原意是指调用方，或者说客户端只需依赖必要的部分能力，即按需依赖，部分依赖。
初一看有点像单一职责的味道，对吧。即强调我们在设计接口的时候，对于不同的业务功能点，需要通过设计不同的接口，从而实现隔离。让调用方只关注依赖必要的能力。满足了该要求，那么我们说满足接口隔离原则。
2.5.依赖倒置原则
依赖倒置原则，有时候我们也叫它依赖反转原则。它的原意是指一个软件应用系统，我们应该让上层依赖下层，而不应该让下层依赖上层。这里的上下层如何理解呢？
举个例子，在我们日常开发中，很多项目都会基于MVC分层模型进行开发，可能有暴露接口的rest层，处理业务的service层，访问数据库的dao层。
根据客户端浏览器的一次请求响应流程，是rest层--->调用service层--->调用dao层。这里我们说rest是service的上一层，service是dao的上一层，即rest层依赖service层，service层依赖dao层，反过来则不成立。
这即是上层依赖下层，下层不依赖上层，即我们说的依赖倒置原则。
