Android 之 OO Principle（面向对象的原则）

OO Principle（面向对象的原则）

OO 是什么

一、OOP

① 面向对象(OO)

就是基于对象概念，以对象为中心，以类和继承为构造机制，充分利用接口和多态提供灵活性，来认识、理解、刻划客观世界和设计、构建相应的软件系统。面向对象的基本特征：封装、继承、多态。

②OO设计原则(OOP)

概念性的，理想的最佳实践，开放性的。方法论上是模糊的。

③OO设计模式(OODP)

解决具体问题的具体方法。实现了OOP。

考虑设计模式的最根本原因在于变化。包括modification和extension。最常说到的词就是封装变化和松耦合，重用和扩展，可维护性

二、耦合性

① 函数的松耦合：把某个具体的功能提取出来。

在多处可能都需要作同一件事情，而这一件事情未来可能需要修改或者扩展，这时候考虑用函数来封装之。当有改变需要发生时，只需要函数改变即可，而不用每一处都更改，这是一种松散耦合。

②类的松耦合：继承是强耦合，接口调用是松耦合。

继承中派生类的实现要依赖于基类的实现，而基类又通过虚函数调用派生类的代码。基类的内部实现必 然是强耦合的，派生类可以看到这种强耦合的实现，就不可避免的依赖于这种强耦合，因而带来了派生类与基类之间的强耦合。而接口继承则可以避免这一点，一个类从一个接口继承，它仅仅能看到接口规范，只要接口规范满足，内部如何实现其它类并不关心。

类的继承比组合耦合性更强。

③架构的松耦合：MV*（例如MVC，MVP，MVVP）

OO 常用六大原则

OO的常用六大原则是指SRP、ISP、OCP、LSP、DIP、DRY。

OO的设计原则不仅仅这六种。

如果没有变化，那么使用OO原则都是冗余的。

一、SRP（Single Responsibility Principle）: 单一职责原则

系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。

如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化就可能削弱或者抑制耦合。这种设计会导致脆弱的设计。当变化发生的时候，设计会遭到意想不到的破坏。

内聚Cohesion 其实是SRP原则的另外一个名字。

典型最常用的符合SRP的设计就是分层结构

二、ISP（Interface Segregation Principle）:接口隔离原则

接口不是高内聚的，一个接口可以分成多组方法，那么这个接口就需要使用ISP处理一下。

接口的划分是由使用它的客户程序决定的，客户程序是分离的接口也应该是分离的。

一个接口中包含太多行为时候，导致它们的客户程序之间产生不正常的依赖关系，我们要做的就是分离接口，实现解耦。不应该强迫客户程序依赖它们不需要的使用的方法。

应用了ISP之后，客户程序看到的是多个内聚的接口。

SRP和ISP都强调内聚，前者是面对自我，后者面向客户

三、OCP（Open-Close Principle） : 开闭原则

类应该对修改关闭，对扩展打开。

改动(新的功能)是通过增加代码进行的(灵活性)，而不是改动现有的代码(稳定性)；

OCP的应用限定在可能会发生的变化上，通过创建抽象来隔离以后发生的同类变化。把系统的所有可能的行为抽象成一个抽象底层，这个抽象层要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象层不需修改；同时由于可以从抽象层导出一个或多个新的具体类可改变系统的行为，因此对于可变的部分，系统设计对扩展是开放的。OCP背后的机制就是抽象和多态

在设计的开始就罗列系统所有可能的行为加入到抽象层是不可能的，也是不合算的；对所有的可变因素进行预计和封装也不太现实，因此，开闭原则很难被完全实现，只能在某些模块、某种程度上、某个限度内符合OCP的要求。OCP具有理想主义的色彩，是OOD 的终极目标。

变化一定会存在。对程序中每一个可能的变化都肆意的抽象不是一个好主意，正确的做法是开发人员仅仅对频繁变化的部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。面对可能的变化，添加新的实现类，优于接口中添加新方法，优于修改实现类，优于修改接口。OCP原则传递出来这样一个思想：一旦你写出来了可以工作的代码，就要努力保证这段代码一直可以工作。一旦我们的代码质量到了一个水平，我们要尽最大努力保证代码质量不回退。比如代码添加了无数对特定数据的处理，特化的代码越来越多，代码意图开始含混不清，开始退化。OCP是OOD的核心，如果这个原则有效应用，我们就可以获更强的可维护性，可重用，灵活性，健壮性。

四、LSP（The Liskov Substitution Principle）: 里氏替换原则

LSP解释了什么时候使用继承：子类必须能够替换基类。例如，正方形不能继承长方形，正方形和长方形都继承四边形。

最好不要从具体类派生 。实体类会具有和特定实体相关的方法，这些方法在子类中可能不会有用。

使用契约式编程方法。DBC（Design by Contract）把类和其客户之间的关系看作是一个正式的协议，明确各方的权利和义务。在父类里定义好子类需要实现的功能，而子类只要实现这些功能即可。

五、DIP（Dependency Inversion Principle）：依赖倒置原则

可以通过抽象方法多态，但是尽量不要重写。

高层模块不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

什么是高层模块？V 高于 C， C高于M

由于对低层模块的依赖，高层模块无法在没有底层模块的上下文环境中独立运行。高层模块无法实现复用。

如果高层依赖于低层，高层和底层其实就在同一层。

这里的倒置不仅仅是依赖关系的倒置也是接口所有权的倒置。应用了DIP我们会发现往往是客户拥有抽象的接口，而服务者从这些抽象接口派生。这就是著名的Hollywood原则：“Don‘t call us， we’ll call you。”底层模块实现了在高层模块声明并被高层模块调用的接口。

六、DRY（Don’t Repeat Yourself Principle）：不要自我重复原则

通过抽取公共部分放置在一个地方避免代码重复.

DRY 很简单，但却是确保我们代码容易维护和复用的关键。

避免重复代码候是确保每一个需求和功能在你的系统中只实现一次，否则很难维护和复用

DRY 原则衍生出的要求：系统信息和行为都放在一个单一的，明显的位置。

DRY 原则衍生出的要求：如何对系统职能进行良好的分割，职责清晰的界限一定程度上保证了代码的单一性。

OO 最佳实践

①封装变化

②面向接口编程而非实现

③优先使用组合而非继承