abstract & interface

abstract

最近在看公司代码时候，看到其对 retrofit 网络请求框架封装的时候，才发现原来 abstract 可以与泛型和接口结合起来实现如此美妙的抽象化。

路漫漫其修远兮......

Java 提供了一个叫做抽象方法的机制，这种方法是不完整的，仅有声明而没有方法体。

abstract void f();

包含抽象方法的类即为抽象类，且其必须被限定为抽象的！抽象类是提取出的关于某类事物的基础特征，但其对象几乎没有任何的意义，编译器也会确保抽象类的纯粹性！而我们创建抽象类，是希望通过通用接口去操纵一系列类，也就是说，就我理解的是，“所有继承我抽象类的都需具备我所定义的属性（接口方法）并为我用之。”

含有接口的抽象类

一个抽象出来的BaseFragment

创建抽象类与抽象方法非常有用，他们可以使类的抽象性明确起来，也就是说你继承实现我这个抽象类你应该做些什么，并能够告诉用户和编译器怎么使用他们。抽象类可以帮助我们将公共方法沿着继承层次结构向上移动，是一个很有用的重构工具。

interface

interface 关键字使抽象的概念更向前一步，他不仅仅只局限于某些类及类的继承者里面，而是还会把一些具体的相类似功能或特征直接抽象出来。一个接口表示：“所有实现了该特定接口的类看起来都像这样”。任何使用某特定接口的代码都知道可以调用该接口的哪些方法，接口可用来创建类与类之间的协议。

在使用适配器与接口的方式中，适配器中的代码接受你所有的接口并可产生你所需要的接口，可令接口从具体实现中解耦出来使得接口可应用于多种不同的实现，因此代码也就可更具复用性。如下Processor接口应用实现的是Filter的process方法

接口与适配器

另外，interface其实是一个极度抽象的类，具有向上转型的特性来实现某种类似多重变种继承的特性。在此可以找到接口的一种常见的用法：“你可以用任何你想要的对象来调用我的方法，只要你的对象遵循我的接口。”这也是使用接口的核心原因，为了能够向上转型为多个基类型（以及由此带来的灵活性）

“Hero可向上转型为所具备的三个属性接口”

另外，接口可通过继承关系来扩展接口，接口中的域自动都是static和final的。在 Java SE5 之前，接口可用来产生与 C 或 C++ 中的 enum （枚举类型）相同效果类型的唯一途径，是一种很便捷的用来创建常量组的工具。关于嵌套接口， 实现一个private接口只是一种方式，他可以强制接口中的方法定义不要添加任何类型信息（也就是说，不允许向上转型），而且private接口不能在定义他的类之外被实现。嵌套接口的这些规则都需遵循严格的语法一致性。

最后，关于到底是用抽象类还是使用接口呢？“确定接口是理想选择，因而应该总是选择接口而不是具体的类。”这其实是一种引诱。恰当的原则是优先选择类而不是接口。就我个人的理解，如果是关于基类的某个功能需求实现的抽象化并有利于所继承类的不同实现与使用，则运用抽象类；若是不限于所衍生的子类，抽象出具体的功能、状态、监听等，则更多的选择接口。当然，这一切还是应结合实际项目需求，以减少额外复杂性为目的进行。

任何抽象性都应该是应真正需求而产生的。

本文更多的是我看《Java编程思想》后的摘录，感谢作者Bruce Eckel。