面向对象的六大原则

还记得我刚开始接触java的时候，刚一开始学感觉还挺简单，什么if啊变量、常量啊等基础知识，感觉还挺好理解，但是当开始接触面向对象这个思想的时候，顿时就蒙了，当时脑子里转不过圈，无法理解这种思维，懵懵懂懂的接触了一两个月，反过来再一想时，自己才有自己的理解，对面向对象也是开始慢慢的明白了。好了这篇文章就简单介绍一下**面向对象中的六大原则**：

**一、优化代码的第一步————单一职责原则：**
单一职责原则的英文名称是Single Responsibility Principle,缩写SRP，SRP的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。
不过单一职责的划分界限并不总是那么的清晰，很多时候都是需要靠个人经验来界定，其实，最大的问题就是对职责的定义，什么是类的职责以及怎么划分类的职责。
其实单一职责还是要看“单一”这两个字，我们不能写一个类里面既有逻辑的处理又有界面的处理，有可能还有数据的解析等，其实这逻辑处理、界面处理、数据解析这三个完全是三个不同的功能，如果都写到一块的话，这样我们的这个类就充当了好几个角色，同时有好几个职责。这是我们如果把这三个功能都抽出来，每个类对应一种功能，这样每个类也就是一个职责了，这就是我们面向对象的单一职责原则。但是具体这职责怎么划分，这个功能怎么划分，有可能我们每个人的划分方式不同，所有这个单一职责原则在我们实际中，根据个人的看法，个人的经验、具体的业务逻辑而定，但是，它也有一些基本的指导原则，例如，两个完全不一样的功能就不应该放在一个类中。在实际中，我们可以不断地审视自己的代码，根据具体的业务、功能对类进行相应的拆分，这是我们程序员优化代码的第一步。

**二、让程序更稳定、更灵活————开闭原则：**

开闭原则的英文全称是Open Close Principle，缩写是OCP，它是java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）**应该对于扩展是开放的，但是，对于修改是封闭的**。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然在现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，因此，在实际的开发中，修改原有代码、扩展代码往往是同时存在的。
其实开闭原则就是在开发中我们能使用扩展实现的，就应该尽量使用扩展，而不是通过修改已有的代码来实现。不过这里的“应该尽量”4个字说明OCP原则并不是绝对不可以修改原始类的。当我们嗅到原来的代码“腐化气味”时，应该尽早的重构，以便使代码恢复到正常的“进化”过程，而不是通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余。我们的开发过程中也没有那么理想化的状况，完全地不用修改原来的代码，因此，在开发过程中需要自己结合具体情况进行考量，是通过修改旧代码还是通过继承使得软件系统更稳定、更灵活，在保证去除“代码腐化”的同时，也保证原有模块的正确性。

**三、构建扩展性更好的系统————里氏替换原则：**

里氏替换原则英文全称是Liskov Sblstrtution Principle,缩写是LSP，LSP的第一种定义是：如果对每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都代换称O2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。上门这种描述确实不太好理解，我们再看看另一个直截了当的定义。里氏替换原则第二种定义：所有引用基类的地方必须能透明地使用其子类的对象。
我们知道面向对象有三大特点是集成、多态、封装，里氏替换原则就是依赖于继承、多态这两大特性，里氏替换原则简单来说就是，所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方父类就未必能适应。说了那么多，其实最终总结就两个字：抽象。
里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，在OOP当中，继承的优缺点都相当明显。优点有以下几点：
（1）代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性；
（2）子类与父类基本相似，但又与父类有所区别；
（3）提高代码的可扩展性；
继承的缺点：
（1）继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
（2）可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的属性和方法；
里氏替换原则其实就是建立抽象，通过抽象建立规范，具体的实现在运行时替换掉抽象，保证系统的扩展性、灵活性。开闭原则和里氏替换原则往往是生死相依、不离不弃的，通过里氏替换来达到对扩展开放，对修改关闭的效果。

**四、让项目拥有变化的能力————依赖倒置原则：**

依赖倒置原则英文全称是Dependeence Inversion Principle,缩写是DIP。依赖倒置原则指代了一种特定的解耦形式，使得高层次的模块不依赖低层次的模块的实现细节的目的，依赖模块被颠倒了。
依赖倒置原则有以下几个关键点：
（1）高层模块不应该依赖低层模块，两者都应该依赖其抽象；
（2）抽象不应该依赖细节；
（3）细节应该依赖抽象；
在java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的：细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化，也就是可以加上一个关键字new产生一个对象，高层模块就是调用端，低层模块就是具体实现类。依赖倒置原则在java语言中的表现是：**模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。**这又是一个将理论抽象化的实例，其实一句话就可以概括：面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或抽象类。
如果类与类直接依赖于细节，那么它们之间就有直接的耦合，当具体实现需要变化时，意味着要同时修改依赖者的代码，这限制了系统的可扩展性。

**五、系统有更高的灵活性————接口隔离原则：**

接口隔离原则英文全称是InterfaceSegregation Principles,缩写是ISP。ISP的定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。说白了就是，让客户端依赖的接口尽可能的小。

**六、更好的可扩展性————迪米特原则：**

迪米特原则英文全称为Law of Demeter，缩写是LOD，也称为最少知识原则。虽然名字不同，单描述的是同一个原则：一个对象应该对其他对象有最少的了解。通俗的讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部实现与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不用管。类与类之间爱那个的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
迪米特原则还有一个英文解释是Only talk to your immedate friends,翻译过来就是：只与直接的朋友通信，下面举个例子说明一下。
我们以租房为例来讲解一下：
一般租房我们都是通过中介，我们一般会有一些条件，如：房子的租金、面积等。这时会有一个房间（Room）类、一个中介（Mediator）类、一个租户（Tenant）类。Room类不用说了就是房子的信息，Mediator类会有一个方法存放所有的房子，还有一个方法返回所有的Room。我们Tenant类的话首选要通过Mediator获取到他手里的所有Room，然后再把这些Room和我们的条件相比，得到我们想要的房子。从上面这个过程中我们可以看到，Tenant类不只依赖了Mediator类，还需要和Room类打交道。这样Mediator类的功能就被弱化，而且导致Tenant类和Room类的耦合较高，因为Tenant必须知道许多关于Room的细节，当Room变化时Tenant也必须跟着变化。Tenant又与Mediator耦合，这就出现了纠缠不清的关系。
因为上面这种情形耦合度太高，所有我们需要进行解耦，首先要明确的是我们只和我们的直接朋友通信，也就是Tenant类和Mediator类，我们把我们需要的条件直接给Mediator类，然后里面具体怎么处理，让Mediator来处理，然后让Mediator直接把符合条件的Room返回回来就行，我们Tenant类就直接获取到Room就可以，不用再和Room类打交道了。（当然这种情形可能和我们显示中租房是有区别的）

**总结：**

在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化。拥抱变化也就意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了各版本的变更之后依然保持清晰、灵活、稳定的系统架构。当然，这是一个比较理想的情况，但我们必须要朝着这个方向去努力，那么遵循面向对象六大严重就是我们走向灵活软件之路所迈出的第一步。