接口概念:在 Java 程序设计语言中, 接口不是类,而是对类的一组需求描述,这些类要遵从接口描 述的统一格式进行定义 。
接口中的所有方法自动地属于 public 。 因此,在接口中声明方法时,不必提供关键字 public。
在接口中可以定义常量。然而,更为重要的是要知道接口不能提供哪些功能。接口绝不能含有实例域 。
在JavaSE 8时,可以在接口中提供简单方法了。当然, 这些方法不能引用实例域——接口没有实例。
提供实例域和方法实现的任务应该由实现接口的那个类来完成。因此,可以将接口看成是没有实例域的抽象类,但是这两个概念还是有一定区别的。
要将类声明为实现某个接口, 需要使用关键字 implements。 为了让类实现一个接口, 通常需要下面两个步骤: 1 ) 将类声明为实现给定的接口。 2 ) 对接口中的所有方法进行定义。
在接口声明中,不需要将方法声明为 public , 这是因为在接口中的所有方法都自动地是 public 。不过,在实现接口时, 必须把方法声明为 public。
接口不是类,尤其不能使用 new运算符实例化一个接口。
尽管不能构造接口的对象,却能声明接口的变量。
Comparable x ; // OK
接口变量必须引用实现了接口的类对象 。
x = new Employee (. . .); // OK
如同使用 instanceof检查一个对象是否属于某个特定类一样, 也可以使用 instanceof 检查一个对象是否实现了某个特定的接口。
if (anObject instanceof Comparable) { . . . }
与可以建立类的继承关系一样,接口也可以被扩展,使用关键字 extends。这里允许存在多条从具有较高通用性的接口到较高专用性的接口的链。
接口中的方法都自动地被设置为 public —样,接口中的域将被自动设为 public static final。
可以将接口方法标记为 public, 将域标记为 public static final。有些程序员出于习惯或提高清晰度的考虑,愿意这样做。但 Java 语言规范却建议不要书写这些多余的关键字。
每个类只能够拥有一个超类, 但却可以实现多个接口。这为定义类的行为提供了极大的灵活性。
在 Java SE 8 中,允许在接口中增加静态方法。理论上讲,没有任何理由认为这是不合法的。只是这有违于将接口作为抽象规范的初衷。
目前为止, 通常的做法都是将静态方法放在伴随类中。在标准库中, 你会看到成对出现的接口和实用工具类, 如 Collection/Collections 或 Path/Paths 。
在Java SE 8 中, 可以为 Path 接口增加静态方法,这样一来, Paths 类就不再是必要的了。 不过整个 Java 库都以这种方式重构也是不太可能的, 但是实现你自己的接口时,不再需要为实用工具方法另外提供一个伴随类。
在 Java SE 8 中,可以为接口方法提供一个默认实现。 必须用 default 修饰符标记这样一个方法。
有些情况下, 默认方法可能很有用。例如,只对接口中的某几个方法感兴趣,而不是全部。
默认方法可以调用任何其他方法。
在 JavaAPI 中,你会看到很多接口都有相应的伴随类,这个伴随类中实现了相应接口 的部分或所有方法,如
Collection/AbstractCollection 或
MouseListener/MouseAdapter。在 JavaSE 8 中, 这个技术已经过时。现在可以直接在接口中实现方法。
默认方法的一个重要作用是“‘ 接口演化” (interface evolution)。 对于一些老版本的接口,如果要在上面增添新功能时,默认方法就不失为一个好的选择,因为默认方法不会对以前的接口实现产生影响。为接口增加一个非默认方法不能保证“源代码兼容”(source compatible)。
如果先在一个接口中将一个方法定义为默认方法, 然后又在超类或另一个接口中定义了 同样的方法, 会发生什么情况? Java 的规则要简单得多。
千万不要让一个默认方法重新定义 Object 类中的某个方法。例如,不能为 toString 或 equals 定义默认方法, 尽管对于 List 之类的接口这可能很有吸引力, 由于“ 类优先” 规则, 这样的方法绝对无法超越 Object.toString 或 Objects.equals。