java - 为什么必须在 Java 中声明接口(interface)？

Question

有时我们有几个类，它们的某些方法具有相同的签名，但并不对应于已声明的 Java 接口(interface)。例如，JTextField 和 JButton(以及 javax.swing.* 中的其他几个方法)都有一个方法

public void addActionListener(ActionListener l)

现在，假设我想对具有该方法的对象做一些事情；然后，我想要一个接口(interface)(或者可能自己定义它)，例如

  public interface CanAddActionListener {
      public void addActionListener(ActionListener l);
  }

这样我就可以写:

  public void myMethod(CanAddActionListener aaa, ActionListener li) {
         aaa.addActionListener(li);
         ....

但是，遗憾的是，我不能:

     JButton button;
     ActionListener li;
     ...
     this.myMethod((CanAddActionListener)button,li);

这种转换是非法的。编译器知道 JButton 不是 CanAddActionListener，因为该类尚未声明实现该接口(interface).. .但是它“实际上”实现了它。

这有时会带来不便 - Java 本身已经修改了几个核心类以实现由旧方法组成的新接口(interface)(例如，String implements CharSequence)。

我的问题是:为什么会这样？我理解声明一个类实现一个接口(interface)的效用。但是不管怎样，看看我的例子，为什么编译器不能推断出 JButton 类“满足”接口(interface)声明(在其中查看)并接受强制转换？是编译器效率的问题还是有更根本的问题？

我对答案的总结:在这种情况下，Java 可以考虑一些“结构类型”(一种鸭子类型(duck typing) - 但在编译时检查)。它没有。除了一些(我不清楚的)性能和实现困难之外，这里还有一个更基本的概念:在 Java 中，接口(interface)的声明(通常是所有内容)不仅仅是结构性的(拥有带有这些签名的方法)但语义:这些方法应该实现一些特定的行为/意图。因此，结构上满足某些接口(interface)的类(即它具有具有所需签名的方法)不一定语义上满足它(一个极端的例子:回想一下“标记”接口(interface)”，甚至没有方法!)。因此，Java 可以断言一个类实现了一个接口(interface)，因为(且仅因为)这已被显式声明。其他语言(Go、Scala)有其他的哲学。

Answer 1

Java 的设计选择是让实现类明确声明它们实现的接口(interface)，这只是一个设计选择。可以肯定的是，JVM 已针对此选择进行了优化，并且实现另一种选择(例如 Scala 的结构类型)现在可能会带来额外的成本，除非并且直到添加一些新的 JVM 指令。

那么， 设计选择究竟是关于什么的？这一切都归结为方法的语义。考虑:以下方法在语义上是否相同？

• 绘制(字符串图形形状名称)
• 绘制(字符串手枪名称)
• draw(String playingCardName)

所有这三个方法都具有签名draw(String)。人们可能会从参数名称或阅读一些文档中推断出它们具有不同的语义。机器有什么方法可以区分它们吗？

Java的设计选择是要求类的开发者显式声明方法符合预定义接口(interface)的语义:

interface GraphicalDisplay {
    ...
    void draw(String graphicalShapeName);
    ...
}

class JavascriptCanvas implements GraphicalDisplay {
    ...
    public void draw(String shape);
    ...
}

毫无疑问，JavascriptCanvas中的draw方法是为了配合draw方法进行图形显示。如果有人试图通过一个要拔出手枪的物体，机器可以检测到错误。

Go 的设计选择更加自由，允许在事后定义接口(interface)。具体类不需要声明它实现的接口(interface)。相反，新纸牌游戏组件的设计者可能会声明提供纸牌的对象必须具有与签名 draw(String) 相匹配的方法。这样做的好处是可以使用任何具有该方法的现有类而无需更改其源代码，但缺点是该类可能会拿出手枪而不是扑克牌。

duck-typing 语言的设计选择是完全放弃正式接口(interface)，而只是匹配方法签名。接口(interface)(或“协议(protocol)”)的任何概念都是纯粹的惯用语，没有直接的语言支持。

这些只是众多可能的设计选择中的三种。这三者可以这样概括:

Java:程序员必须显式声明他的意图，机器会检查它。假设程序员很可能会犯语义错误(图形/手枪/卡片)。

Go:程序员必须至少声明他的部分意图，但机器在检查它时没有什么可继续的。假设程序员可能会犯笔误(整数/字符串)，但不太可能犯语义错误(图形/手枪/卡片)。

Duck-typing:程序员不需要表达任何意图，机器也不需要检查什么。假设程序员不太可能犯笔误或语义错误。

解决接口(interface)和一般类型是否足以测试书写和语义错误的问题超出了本答案的范围。完整的讨论必须考虑构建时编译器技术、自动测试方法、运行时/热点编译和许多其他问题。

众所周知，draw(String) 示例被故意夸大以表明观点。真实示例将涉及更丰富的类型，这些类型将提供更多线索来消除方法歧义。