Java抽象接口

考虑一个示例（在Java中编译）

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

为什么必须将接口“声明”为抽象的？还有其他适用于抽象接口的规则吗？

最后：如果abstract过时，为什么将它包含在Java中？有抽象接口的历史吗？

为什么必须将接口“声明”为抽象的？

不是。

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

接口及其方法是隐式的abstract，添加该修饰符没有区别。

还有其他适用于抽象接口的规则吗？

不，适用相同的规则。该方法必须由任何（具体）实现类来实现。

如果抽象已经过时，为什么它包含在Java中？有抽象接口的历史吗？

有趣的问题。我挖出了第一 JLS的版本，甚至还有它说：“这个修改是过时的，不应该在新的Java程序中使用”。

好的，进一步挖掘 ...碰到许多断开的链接后，我设法找到了原始的Oak 0.2 规范（或“手册”）的副本。我必须说非常有趣的阅读，总共只有38页！:-)

在第5节“接口”下，提供以下示例：

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

边上说

将来，接口中声明方法的“ = 0”部分可能会消失。

假设=0被abstract关键字替换，我怀疑这abstract在某种程度上对于接口方法是必需的！

相关文章：Java：抽象接口和抽象接口方法

就像public接口方法一样，这不是必需的，而是可选的。

参见JLS：

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1抽象接口每个接口都是隐式抽象的。该修饰符已过时，不应在新程序中使用。

和

9.4抽象方法声明

[...]

为了与Java平台的较早版本兼容，出于样式考虑，允许但不鼓励为接口中声明的方法冗余地指定abstract修饰符。

允许（但强烈建议您避免样式）为接口方法多余地指定public修饰符。

不必声明接口抽象。

就像将所有这些方法声明为公共（如果接口是公共的，它们已经是）或抽象（它们已经在接口中的）那样都是多余的。

但是，没有人阻止您。

您可以明确声明的其他内容，但不需要：

• 在构造函数的第一行调用super（）
• extends Object
• 实现继承的接口

还有其他适用于抽象接口的规则吗？

接口已经是“抽象的”。再次应用该关键字绝对没有区别。

请注意，在春季它没有学术意义。抽象接口向开发人员发出警告，请不要将其用于@Autowired。我希望spring / eclipse @Autowired会查看此属性，并警告/失败有关此属性的用法。

一个真实的例子：@Transnational下的@Service代理到@Repository需要使用相同的基本方法，但是由于，它们应该使用不同的接口来扩展此抽象接口@Autowired。（我将此称为XXXSpec接口）

每个接口都是隐式抽象的。
该修饰符已过时，不应在新程序中使用。

[Java语言规范-9.1.1.1 abstract接口]

另请注意，接口成员方法是隐式的public abstract。
[Java语言规范-9.2接口成员]

为什么这些修饰符是隐式的？在此没有其他修饰符（甚至没有 ' no Modify'- modifier），因此您不必显式键入它。

没必要 这是一种语言的怪癖。

不必要，因为默认情况下接口是抽象的，因为接口中的所有方法都是抽象的。

至少从理论上讲，抽象接口并不像每个人都说的那样多余。

可以像类一样扩展接口。如果您为应用程序设计接口层次结构，则可能会有一个“基础”接口，您可以从中扩展其他接口，但不希望将其本身作为对象。

例：

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

您不希望Class实现MyBaseInterface，仅希望其他两个实现MMyDog和MyBoat，但是两个接口都共享MyBaseInterface接口，因此具有“名称”属性。

我知道它有点学术，但是我认为有些人可能会觉得它很有趣。:-)

在这种情况下，它实际上只是一个“标记”，用于向接口的实现者发出信号，告知它并非旨在单独实现。我应该指出一个编译器（至少是我尝试过的sun / ora 1.6）编译了一个实现抽象接口的类。

“抽象接口”是一个词汇构造：http : //en.wikipedia.org/wiki/Lexical_analysis。

编译器需要它，您也可以编写interface。

好吧，不要过多地关注语言的Lexical构造，因为他们可能会把它放在这里以解决某些编译歧义，这在编译过程中或为向后兼容而被称为特殊情况，请尝试着眼于核心Lexical构造。

接口的本质是捕获一些抽象概念（思想/思想/高阶思维等），其实现可能会有所不同……也就是说，可能有多种实现。

接口是纯抽象数据类型，表示它正在捕获或表示的对象的功能。

要素可以用空间或时间来表示。当它们由空间（内存存储）表示时，这意味着您的具体类将实现一个字段以及将对该字段或时间进行操作的方法/方法，这意味着实现该功能的任务纯粹是计算性的（需要更多的cpu时钟进行处理），因此您需要在空间和时间之间进行权衡。

如果您的具体类没有实现所有功能，则由于您已经实现了您的思想，观念或抽象性，但是又不完整，那么您又会变得抽象，您可以按abstract类指定它。

一个具体的类将是一个类/一组类，它将完全捕获您要捕获的类XYZ的抽象性。

所以模式是

Interface--->Abstract class/Abstract classes(depends)-->Concrete class