抽象的接口并不像每个人说的那样多余，至少在理论上是这样。

接口可以被扩展，就像类一样。如果你为你的应用程序设计一个接口层次结构，你可能有一个“基础”接口，你从but扩展其他接口 不想要作为一个对象本身。

例子:

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

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

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

你不需要一个类来实现MyBaseInterface，只需要另外两个，MMyDog和MyBoat，但两个接口共享MyBaseInterface接口，所以有一个'name'属性。

我知道这有点学术，但我想有些人可能会觉得很有趣。: -)

在这种情况下，它实际上只是一个“标记”，向接口的实现者发出信号 并不是为独立实现而设计的。我应该指出一个编译器(至少我尝试了sun/ora 1.6)编译一个实现抽象接口的类。

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

请看下面的JLS:

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

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

And

9.4抽象方法声明 […] 为了与旧版本的Java平台兼容，它是 作为一种风格，允许但不鼓励冗余 为接口中声明的方法指定抽象修饰符。 这是允许的，但作为一种风格问题，强烈不鼓励 冗余地为接口方法指定公共修饰符。

不需要声明接口抽象。

就像声明所有这些方法是公共的(如果接口是公共的，它们已经是公共的)或抽象的(它们已经在接口中是公共的)是多余的。

不过，没人会阻止你。

其他你可以明确声明的事情，但不需要:

在构造函数的第一行调用super() 扩展对象 实现继承接口

是否有其他规则适用于抽象接口?

接口已经是“抽象的”了。再次应用这个关键字完全没有区别。

这是不必要的。这是语言的怪癖。

注意，在春季，它没有学术意义。 抽象接口是对开发人员的警告，不要将其用于@Autowired。 我希望spring/eclipse @Autowired能够查看这个属性，并警告/fail使用该属性。

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

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