第1章 面向对象的六大原则

前言

这是我在读《Android源码设计模式解析与实战》所摘抄的笔记。

一直以来就觉得自己敲的代码质量太渣渣了，一看就知道是菜鸟写的代码（其实自己现在确实还是一枚开发菜鸟- -！）。正好现在按照自己的学习计划一步一步地来，在这个学习阶段中，想在代码的二次封装上有所进步和突破，就买了这本书，好好学习理解下面向对象和一些常用的设计模式，并且强迫自己养成读书，写博客的习惯。见证自己从菜鸟向大X迈进。

单一职责原则（SRP）——优化代码的第一步

就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。

单一职责原则其实是挺容易理解的，就是你当初设定这个类是用来实现什么功能的的就只能用来实现这个功能，如果还去实现其他功能的话，那么这样就违背了这个原则。

在实现这个原则，最大的问题是对职责的定义，什么事类的职责，以及怎么去划分类的职责。

开闭原则（OCP）——让程序更稳定、更灵活

软件中的对象（类、模块、函数等）应该对于拓展是开放的，但是，对于修改是封闭的。

在对软件的升级和维护等过程中，需要对软件的原有的代码进行修改的话，就有可能会将错误引入原本已经通过测试的旧代码中，破环原有的系统。因此当软件需要变化时，我们应该尽量通过拓展的方式来实现变化，而不是通过修改已有的代码来实现。

当然，在现实的开发中，只通过继承的方式来升级、维护原有的系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、拓展代码往往是同时存在的。

里氏替换原则（LSP）——构建拓展性更好的系统

所有引用基类（父类）的地方必须能透明地使用其子类的对象。

里氏替换原则就是依赖于继承、多态这两大特征。只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或者异常，使用者可能根本就不需要知道是父类还是子类。其实最终总结就是两个字：抽象

里氏替换原则的核心原理就是抽象，抽象又依赖于继承这个特性，在面向对象中，继承的优缺点都相当明显。

• 优点：

  1. 代码的重用，减少创建类的成本，每个子类都拥有父类的方法和属性；
  2. 子类与父类基本相似，但是又与父类有所区别；
  3. 提高了代码的可拓展性。

• 缺点：

  1. 继承是侵入性的，只有继承就必须拥有父类的所有属性和方法；
  2. 可能造成子类代码的冗余、灵活性降低，因为子类必须拥有父类的属性和方法。

依赖倒置原则(DIP)——让项目拥有变化的能力

指代了一种特定的解耦形式，使得高层次的模块不依赖低层次的模块的实现细节的目的，依赖模块被颠倒了。

依赖倒置原则有以下几个关键点：

1. 高层模块不应该依赖于低层模块，两者都应该依赖其抽象；
2. 抽象不应该依赖细节；
3. 细节应该依赖抽象。

高层模块就是调用端，低层模块就是具体的实现类。依赖倒置原则在Java语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的。

一句话概括：依赖抽象，而不依赖具体实现。

接口隔离原则（ISP）——系统有更高的灵活性

客户端不应该依赖它不需要的接口（类间的依赖关系应该建立在最小的接口上）

接口隔离原则将非常庞大、臃肿的接口拆分成更小的、更具体的接口，这样客户将会只需知道他们感兴趣的方法。

接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。

迪米特原则（LOD）——更好的拓展性

迪米特原则，也称做少知识原则。一个对象应该对其他对象有最少的了解。

一个类应该对自己需要耦合或者调用的类知道的最少，类的内部知道如何实现与调用者或者依赖着没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不管。

举一个租房的例子：我只要求房间的面积和租金，其他的一概不管，中介将符合我要求的房子提供给我就好可以了。

总结

这六条原则就是面向对象的六大原则，只有理解透了，铭记和遵循着这六大原则，是在后续的升级、维护的过程让应用拥抱变化，保持高可拓展性，高内聚，低耦合的前提，也是写好代码，优化代码，提高代码质量的前提。