第一章 走灵活软件之路 —— 面向对象的六大原则
- 优化代码的第一步 —— 单一职责原则
单一职责原则的英文名称为 Single Responsibility Principe，缩写为 SRP，定义是：就一个类而言，应该就有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。
- 让程序更稳定、更灵活 —— 开闭原则
开闭原则的英文全称是 Open Close Principe，缩写为 OCP，它是 Java 世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。其定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有的代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然，在现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，在实际开发过程中，修改原有代码、扩展代码往往是同时存在的。
- 构建扩展性更好的系统 —— 里氏替换原则
里氏替换原则英文全称是 Liskov Substitution Principle，缩写是 LSP。LSP 的第一种定义是：如果对每一个类型为 S 的对象 O1，都有类型为 T 的对象 O2，使得以 T 定义的所有程序 P 在所有的对象 O1 都代换成 O2 时，程序 P 的行为没有发生变化，那么类型 S 是类型 T 的子类型。上面的这种定义不太好理解，里氏替换原则的第二种定义：所有引用基类的地方必须能够透明地使用其子类的对象。面向对象的语音的三大特点是继承、封装、多态，里氏替换原则就是依赖于继承、多态这两大特性。里氏替换原则简单来说就是：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或者异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。总结起来就是两个字：抽象。
里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，在 OOP 当中，继承的优缺点都相当明显，优点有如下几点：
（1）代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性；
（2）子类与父类基本相似，但又与父类有所区别；
（3）提高代码的可扩展性。
继承的缺点：
（1）继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
（2）可能造成子类代码的冗余，灵活性降低，因为子类必须拥有父类的属性和方法。
里氏替换原则提供了指导原则：也就是建立抽象，通过抽象建立规范，具体的实现在运行时替换掉抽象，保证系统的扩展性、灵活性。开闭原则和里氏替换原则往往是生死相依、不离不弃的，通过里氏替换原则来达到对扩展开放，对修改关闭的效果。然而，这两个原则都同时强调了一个 OOP 的重要特性 —— 抽象，因此，在开发过程中运用抽象是走向代码优化的重要一步。
- 让项目拥有变化的能力 —— 依赖倒置原则
依赖倒置原则英文全称是 Dependence Inversion Principle，缩写是 DIP。依赖倒置原则指代了一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。
依赖倒置原则的几个关键点：
（1）高层模块不应该依赖低层模块，两者都应该依赖其抽象；
（2）抽象不应该依赖细节；
（3）细节应该依赖抽象。
在 Java 语言中，抽象就是指接口或者抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点是，可以直接被实例化。高层模块就是调用端，低层模块就是具体实现类。依赖倒置原则在 Java 语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。一句话概况就是：面向接口编程，或者说是面向抽象编程，这里的抽象是指接口或抽象类。面向接口编程是面向对象精髓之一，也就是之前强调的抽象。
- 系统有更高的灵活性 —— 接口隔离原则
接口隔离原则的英文全称是 Interface Segregation Principles，缩写是 ISP。ISP 的定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解耦，从而容易重构、更改和重新部署。接口隔离原则说白了就是，让客户端依赖的接口尽可能地小。
- 更好的可扩展性 —— 迪米特原则
迪米特原则英文全称为 Law of Demeter，缩写是 LOD，也称为最少知识原则（Least Knowledge Principle）。定义：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或者调用的类知道得越少越好，类的内部如何实现与调用者或者依赖者没有关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不用考虑。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
迪米特原则还有一个英文解释是 Only talk to your immedate friends，就是：只与直接的朋友通信。通过这简单的几个字就能够将我们从复杂的关系网中剥离出来，降低程序耦合度、提高稳定性。
本文内容参考自《Android 源码设计模式解析与实战》
