java基础两点原则编程原则_面向对象编程内功心法系列三（聊一聊设计原则）...

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层，反过来则不成立。

这即是上层依赖下层，下层不依赖上层，即我们说的依赖倒置原则。