Java面向对象六大原则

前言

面向对象六大原则是Java工程师老生常谈的话题了，但是想要真正理解，融会贯通，并且自然而然的将其运用到开发中可不是一朝一夕的事情。所以，我们要经常温习六大原则和23种设计模式。并且在编码、阅读源码、编写业务代码时多思考，多总结。逐渐深化理解和认知。总有一天，这些东西全部印在脑海中，在编写每一个类、每一个接口，设计每一个业务逻辑时，这些东西自然而然的就到了手边。那时基本就是神功初成，跨入架构师的门槛了。

或许初入行的小伙伴们会有一些疑问：这些东西到底有没有用？我不用这些东西一样可以写代码啊。不要有任何困惑，所有人都是从这阶段过来的。我刚入行第一年时，完全不明白这些高大上的东西到底怎么用。都是每次听大佬和前辈们说这些东西很重要，要学，就机械式的去记、去背，结果收效寥寥。不过，在度过了这一阶段之后，你在编码和设计一些复杂业务时，会遇到瓶颈。苦思冥想也找不到优雅的解决方案，到那时再来回顾这些东西。就会发现，这些前人总结出来的精华简直就是瑰宝，艺术品！

（该篇主要是记录，并附加一些自己的理解。就不长篇大论了~）

注：下文中的“接口”一词并不局限于Java中用Interface关键字定义的接口，而是一种业务抽象的概念。具体实现的话可以通过接口、抽象类等。这个概念切记不要混淆。

 

1.单一职责原则（SRP）

直接从字面就可以理解，单一职责就是：就一个类而言，应该仅有一个引起它变化的原因。（一个类只负责一个职责）

这个原则是封装和解耦的最基础原则，一般有经验的程序员即使不知道这个概念也都会自觉遵守这个原则。

但是，在具体业务中，职责分离也要讲究一个度。过度分离会导致职责扩散，类爆炸。比如：在业务中只有一个职责的类P1，被强行分解成F1、F2···F10这么10个单元。这就属于过度分离。至于这个度具体该怎么把握，就需要综合考量多方面原因，根据具体业务和项目进行分析并设计了。

 

2.开/闭原则（OCP）

开/闭原则即：对扩展开放，对修改关闭。

开闭原则告诉我们应尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来完成变化。它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。

理解倒是也很好理解，不过具体哪些开，哪些闭；怎么开，怎么闭，这就真不是一句两句能说清的了~

 

3.里氏替换原则（LSP）

任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

这个就不多说了，设计继承关系的类时需要遵守的最基础的原则。

 

4.依赖倒置原则（DIP）

依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。其核心思想是：要面向接口编程，不要面向实现编程。

总结一句话就是：面向接口编程。

但是如果要从字面理解这个概念的话是：高层模块不依赖低层模块（正常面向对象逻辑，高层模块是要依赖底层模块的。具体怎么理解下面有例子说明），而是低层模块依赖高层模块的业务抽象（接口）。当然这句话可能不是那么严谨，不过应该是“依赖倒置”这个概念出现时的命名缘由吧。（其实吧，不要过分纠结一个词，和一个字的意义。毕竟很多专业名词都是翻译过来的，存在一些词义的不完全对等。而且随着新技术、新思想的不断迭代，也可能使得一些老概念有一些适应性的调整，它们也并不是一成不变的。所以，大家只要理解核心思想，并把它们吃透就好~）

 

举个栗子：现在有两个类：1.程序员类； 2.电脑类

程序员想要写代码，需要用电脑。那么常规设计流程就是：在程序员类中实例化一个电脑实体，然后通过这个实体去做一些操作，比如：“写代码”。这是我们很常用的标准面向对象设计流程。但是，这么设计的话对拓展不太友好。比如如下两种情况：

1.现在有一个大神，人家非要用笔记本（纸质。别抬杠，这只是一种假设.....）写代码。

2.另一种情况：电脑这个类有变动了。

......

这两种情况是不是都要修改“写代码”这个动作的业务代码。

所以，如果低层类“电脑类”能够依赖于高层类“程序员类”的业务抽象：“写代码”这个动作，那么是不是所有问题都迎刃而解了？

其实废话那么多最终还是一句话：面向接口编程。

 

5.接口隔离原则（ISP）

接口隔离原则：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

这是接口设计时的一个原则，接口设计要高内聚，不要一股脑的把有用的没用的都加进去，这样会造成接口污染。

（*注  接口污染：现在有一个类A实现了一个接口B，接口B中有两个方法b1和b2，但是b2这个功能是类A没有的。这就造成了接口污染）

 

6.迪米特法则（最少知道原则）（LOD）

迪米特法则：一个对象应当对其他对象有尽可能少的了解。

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类（可以简单理解为中介类）来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。