为什么Java中必须声明接口？

有时，我们有多个类，它们的某些方法具有相同的签名，但与声明的 Java 接口不对应。例如，两者JTextField and JButton（其中包括其他几个javax.swing.*）有一个方法

public void addActionListener(ActionListener l)

现在，假设我希望对具有该方法的对象执行某些操作；然后，我想要一个接口（或者也许自己定义它），例如

  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);

这种演员阵容是非法的。编译器knows that JButton is not a CanAddActionListener，因为该类尚未声明实现该接口...然而它“实际上”实现了它.

这有时会带来不便——Java本身修改了几个核心类来实现由旧方法组成的新接口（String implements CharSequence， 例如）。

我的问题是：为什么会这样？我了解声明类实现接口的实用性。但无论如何，看看我的例子，为什么编译器不能推断出该类JButton“满足”接口声明（查看其内部）并接受强制转换？是编译器效率的问题还是还有更根本的问题？

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

Java 的设计选择是让实现类明确声明它们实现的接口，这就是一种设计选择。可以肯定的是，JVM 已针对此选择进行了优化，并且实现另一个选择（例如 Scala 的结构类型）可能会now除非添加一些新的 JVM 指令，否则会产生额外的成本。

那么究竟是什么is设计选择大约是？这一切都取决于方法的语义。考虑一下：以下方法在语义上是否相同？

• drawString 图形形状名称）
• 抽绳手枪名称）
• drawString 扑克牌名称）

所有三个方法都有签名draw(String)。人们可能会从参数名称或通过阅读一些文档来推断它们具有不同的语义。有什么办法让机器知道它们是不同的吗？

Java 的设计选择是要求类的开发人员明确声明方法符合预定义接口的语义：

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

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

毫无疑问，draw中的方法JavascriptCanvas旨在匹配draw图形显示的方法。如果有人试图经过一个要拔出手枪的物体，机器就能检测到错误。

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

鸭子类型语言的设计选择是完全放弃形式接口并简单地匹配方法签名。任何接口（或“协议”）的概念都是纯粹惯用的，没有直接的语言支持。

这些只是许多可能的设计选择中的三个。这三者可以简单地概括如下：

Java：程序员必须明确声明他的意图，机器会检查它。假设程序员可能会犯语义错误（图形/手枪/卡片）。

Go：程序员必须至少声明其意图的一部分，但机器在检查时几乎没有什么可继续进行的。假设程序员可能会犯错误（整数/字符串），但不太可能犯语义错误（图形/手枪/卡片）。

鸭子打字：程序员不需要表达任何意图，机器也不需要检查任何内容。假设程序员不太可能犯笔误或语义错误。

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

据了解，draw(String)为了表达观点而故意夸大例子。真实的例子将涉及更丰富的类型，这将提供更多线索来消除方法的歧义。