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程序中使用”

好的, 进一步挖掘 …击中无数断开的链接后,我设法find原始的Oak 0.2 Specification (或“manual”)的副本。 非常有趣的阅读,我必须说,总共只有38页! 🙂

在第5节“接口”中,它提供了以下示例:

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

并在边缘说

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

假设=0abstract关键字取代,我怀疑这个abstract对于接口方法是强制性的!


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

这是没有必要的,它是可选的,就像在接口方法上public

看到这个JLS:

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

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

9.4抽象方法声明

[…]

为了与Java平台的旧版本兼容,作为样式,允许但不鼓励冗余地指定在接口中声明的方法的抽象修饰符。

这是允许的,但强烈不鼓励作为风格的问题,冗余地指定接口方法的公共修饰符。

没有必要声明接口摘要。

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

但是没有人阻止你。

其他的东西,你可以明确表示,但不需要:

  • 在构造函数的第一行调用super()
  • extends Object
  • 实现inheritance的接口

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

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

请注意,在spring它没有学术意义。 抽象接口是对开发者的警告,不要将它用于@Autowired 。 我希望spring / eclipse @Autowired会看这个属性,并警告/失败这样的用法。

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

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

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

另请注意,接口成员方法隐式public abstract
[Java语言规范 – 9.2接口成员]

为什么这些修饰语是隐含的? 没有其他修饰符(甚至没有“修饰符修饰符 )在这里很有用,所以你没有明确地input它。

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

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

至less在理论上,抽象的接口并不像每个人似乎都这么说。

一个接口可以被扩展,就像一个类可以。 如果你为你的应用程序devise一个接口层次结构,你可能会有一个“基础”接口,你扩展了其他接口,但是不希望作为一个对象本身。

例:

 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'属性。

我知道它有点学术,但我认为有些人会觉得有趣。 🙂

在这种情况下,它实际上只是一个“标记”,向接口的实现者发出信号,而不是devise成独立实现的接口。 我应该指出一个编译器(至less是我试过的sun / ora 1.6)编译一个实现抽象接口的类。

那么'抽象接口'是一个词法构造: http : //en.wikipedia.org/wiki/Lexical_analysis 。

这是编译器所要求的,你也可以编写interface

那么不要过多地使用词汇来构build语言,因为他们可能会把它放在那里来解决编译过程中被称为特殊情况的一些编译歧义,或者为了一些向后兼容性,试图把注意力集中在核心词汇结构上。

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

一个接口是一个纯粹的抽象数据types,代表了它所捕获或表示的对象的特征。

特征可以用空间或时间表示。 当它们由空间(内存存储)表示时,这意味着你的具体类将实现一个字段和方法/方法,将在该字段或时间上运行,这意味着实现该function的任务纯粹是计算的(需要更多的CPU时钟用于处理),因此您可以在空间和时间之间进行权衡以实现function。

如果你的具体类没有实现所有的特性,它就会变成抽象的,因为你有一个思想或者想法或者抽象的实现,但是它并不完整,你可以通过abstract类来指定它。

一个具体的类将是一个类/一组类,它将完全捕获你正在试图捕获类XYZ的抽象性。

所以模式是

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