Android源码设计模式（一） -- 面向对象的六大原则

Android源码设计模式（一） -- 面向对象的六大原则
Android源码设计模式（二）-- 应用最广的模式：单例模式
Android源码设计模式（三）-- 自由扩展你的项目：Builder 模式
Android源码设计模式（四）-- 时势造英雄：策略模式
Android源码设计模式（五）-- 使编程更有灵活性：责任链模式
Android源码设计模式（六）— 编程好帮手：代理模式
Android源码设计模式（七）— 解决、解耦的钥匙 — 观察者模式

简书 MD 语法不识别 [TOC] ,也不会根据标题行(#) 来插入目录,作为每次看资料喜欢先看目录把握总体的我来说,很不习惯,查找跳转也不方便,所以，如果看到文章没有目录预览的，请安装脚本：简书目录脚本地址

一、面向对象的六大原则

1.1、优化代码第一步 -- 单一职责原则（Single Responsibility Principle, SRP）

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

如何划分一个类、一个函数的职责，每个人都有自己的看法，这需要根据个人经验、具体的业务逻辑而定。但是，它也有一些基本的指导原则，例如，两个完全不一样的功能就不应该放在一个类中。一个类中应该是一组相关性很高的函数、数据的封装。工程师可以不断地审视自己的代码，根据具体的业务、功能对类进行相应的拆分，我想这会是你优化代码迈出的第一步。

1.2、让程序更稳定、更灵活 -- 开闭原则（Open Close Principle, OCP）

它是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。

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

在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然，在现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、扩展代码往往是同时存在的。

勃兰特·梅耶在1988年出版的《面向对象软件构造》一书中提出这一原则。这一想法认为，一旦完成，一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类实现。新建的类可以通过继承的方式来重用原类的代码。显然，梅耶的定义提倡实现继承，已存在的实现对于修改是封闭的，但是新的实现类可以通过覆写父类的接口应对变化。

“软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的，这就是开放-关闭原则。也就是说，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。

1.3、构建扩展性更好的系统 -- 里氏替换原则（Liskov Substitution Principle, LSP）

里氏替换原则第一种定义是：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。

里氏替换原则第二种定义：所有引用基类的地方必须能透明地使用其子类的对象。

我们知道，面向对象的语言的三大特点是继承、封装、多态，里氏替换原则就是依赖于继承、多态这两大特性。里氏替换原则简单来说就是，所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。说了那么多，其实最终总结就两个字：抽象。

里氏替换原则就为这类问题提供了指导原则，也就是建立抽象，通过抽象建立规范，具体的实现在运行时替换掉抽象，保证系统的高扩展性、灵活性。开闭原则和里氏替换原则往往是生死相依、不弃不离的，通过里氏替换来达到对扩展开放，对修改关闭的效果。然而，这两个原则都同时强调了一个 OOP 的重要特性——抽象，因此，在开发过程中运用抽象是走向代码优化的重要一步。

1.4、让项目拥有变化的能力 -- 依赖倒置原则（Dependence Inversion Principle, DIP）

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

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

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

在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化，也就是可以加上一个关键字 new 产生一个对象。高层模块就是调用端，低层模块就是具体实现类。依赖倒置原则在 Java 语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。这又是一个将理论抽象化的实例，其实一句话就可以概括：面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或者抽象类。

1.5、系统有更高的灵活性 -- 接口隔离原则（InterfaceSegregation Principles, ISP）

它的定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。

接口隔离原则将非常庞大、臃肿的接口拆分成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。

Bob大叔（Robert C Martin）在 21 世纪早期将单一职责、开闭原则、里氏替换、接口隔离以及依赖倒置（也称为依赖反转）5 个原则定义为 SOLID 原则，指代了面向对象编程的 5 个基本原则。当这些原则被一起应用时，它们使得一个软件系统更清晰、简单、最大程度地拥抱变化。SOLID 被典型地应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发基本原则的重要组成部分。这几大原则最终就可以化为这几个关键词：抽象、单一职责、最小化。

1.6、更好的扩展性 -- 迪米特原则（Law of Demeter, LOD）

迪米特原则，也称为最少知识原则（Least Knowledge Principle）。

一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

二、设计模式分类

设计模式一共 23 种，根据目的准则分类，分为 3 类：

• 创建者设计模式（5 种）：单例模式，工厂方法模式，抽象方法模式，建造者模式，原型模式。
• 结构型设计模式（7 种）：适配器模式，装饰模式，代理模式，外观模式，桥接模式，组合模式，享元模式。
• 行为型设计模式（11 种）：策略模式，模板方法模式，观察者模式，迭代器模式，责任链模式，命令模式，备忘录模式，状态模式，访问者模式，中介者模式，解释器模式。