2011-08-26 85 views
179

考慮這樣一個例子(編譯Java中)Java的抽象接口

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

爲什麼需要一個接口是「申報」抽象?是否有其他適用於抽象接口的規則?


最後:如果abstract已過時,它爲什麼包含在Java中?抽象界面有歷史嗎?

+0

可能重複[爲什麼要聲明一個接口爲抽象?](http://stackoverflow.com/questions/2134200/why-declare-an-interface-as-abstract ) – Thilo

+5

考慮到「*最後:.... *」部分不重複。 – aioobe

+0

這個相關的問題引用了一個真實的例子:http://stackoverflow.com/questions/4380796/what-is-public-abstract-interface-in-java/4381308#4381308 – Raedwald

回答

415

爲什麼需要將接口「聲明」爲抽象?

不是。

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

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

接口和他們的方法隱含abstract並補充說,修改沒什麼區別。

是否有其他規則適用於抽象接口?

不,同樣的規則適用。該方法必須由任何(具體)實施類來實施。

如果abstract已經過時,爲什麼它包含在Java中?抽象界面有歷史嗎?

有趣的問題。我挖出了第一個版的JLS,甚至在那裏它說的是"This modifier is obsolete and should not be used in new Java programs"

好吧,挖進一步 ...打無數斷開鏈接後,我設法找到原Oak 0.2Specification(或「手動」)的副本。我必須說非常有趣的閱讀,總共只有38頁! :-)

根據第5,接口,它提供了以下示例:

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

而且在餘量它說

在未來,的 「= 0」 的一部分在接口中聲明方法可能會消失。

假設=0得到了由abstract關鍵字替換,我懷疑abstract在某一點強制性的接口方法!


相關文章:Java: Abstract interfaces and abstract interface methods

+73

+1挖,我也找不到原因。 :) –

+111

+1努力的漂亮ascii藝術:) – Bohemian

+2

但抽象本身並沒有過時,或?它已經過時了,但仍然有抽象類和方法。 –

35

這不是必需的,它是可選的,就像接口方法中的public一樣。

見JLS在此:

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

9.1.1.1的抽象接口的每個接口是隱式的抽象。 此修飾符已過時,不應在新程序中使用。

而且

9.4抽象方法聲明

[...]

爲了與舊版本的Java平臺的兼容性,它是 允許但不鼓勵,作爲事的樣式,重複地爲 指定在接口中聲明的方法的抽象修飾符。

作爲樣式,允許但強烈不鼓勵 冗餘地指定接口方法的公共修飾符。

+5

給JLS:作爲一種風格,允許但強烈勸阻冗餘地寫出兩個相同含義和幾乎相同字詞的句子...... – n611x007

12

沒有必要聲明接口摘要。

就像聲明所有這些方法是公共的(它們已經是接口是公共的)或抽象的(它們已經在接口中)是多餘的。

雖然沒有人阻止你。

其他的事情你可以明確說明,但並不需要:

  • 調用超()在構造函數的第一行
  • extends Object
  • 實現繼承接口

是否有其他規則適用於抽象接口?

接口已經是「抽象的」。再次應用該關鍵字完全沒有區別。

+2

顯然,如果接口本身就是公開的方法是包私有的。 – Thilo

2

這是沒有必要的。這是一種語言的怪癖。

2

這不是必需的,因爲接口默認是抽象的,因爲接口中的所有方法都是抽象的。

-3

抽象接口並不像每個人似乎至少在理論上所說的那樣多餘。

一個接口可以像Class一樣擴展。如果你爲你的應用程序設計一個接口層次結構,你可能會有一個'基礎'接口,你可以擴展其他接口,但不希望作爲一個對象本身。

例子:

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接口,所以纔有了「名」屬性。

我知道它有點學術,但我想有些人可能會覺得它很有趣。 :-)

在這種情況下,它實際上只是一個「標記」,它向接口的實現者發出信號,表示它不是被設計成獨立實現的。我應該指出一個編譯器(至少是我試過的sun/ora 1.6)編譯一個實現抽象接口的類。

+3

我相信你絕對誤解了我的問題。 –

+3

我不同意這個推理。我認爲每個接口都必須提供完全可用的功能集,因此每個接口都可以自行實現。 也沒有理由讓編譯器拒絕編譯一個實現了明確聲明爲抽象的接口的類,因爲所有接口都已經隱式抽象。這將完全改變「抽象」關鍵字的含義。 – BladeCoder

6

請注意,在春季它沒有學術意義。 抽象界面對開發者是一個警告,不要將它用於@Autowired。 我希望春/日本@Autowired將看這個屬性,並警告/失敗這種用法。

一個真實的例子:@Transnational下@Service代理的@Repository需要使用相同的基本方法,但是他們應該使用擴展因@Autowired這個抽象接口不同的接口。 (我稱之爲XXXSpec接口)

+0

+1好打,我看了一個非易失sessionbean注射的分離。也許我可以使用findbugs/checkstyle作爲規則.... –

-3

好'抽象接口'是一個詞法構造:http://en.wikipedia.org/wiki/Lexical_analysis

它是編譯器要求的,你也可以寫interface

那麼不要太過分的詞彙結構的語言,因爲他們可能會把它放在那裏解決一些編譯歧義,這在編譯過程中被稱爲特殊情況或爲了一些向後兼容性,嘗試專注於核心詞彙構造。

接口的本質是捕捉一些抽象概念(想法/思想/高階思維等),其實現可能會有所不同......也就是說,可能有多種實現。

接口是一種純粹的抽象數據類型,它表示正在捕獲或表示的對象的特徵。

功能可以由空間或時間來表示。當它們由空間(內存存儲)表示時,這意味着具體類將實現將在該字段或時間上運行的字段和方法/方法,這意味着實現該功能的任務純粹是計算性的(需要更多的cpu時鐘用於處理),因此您可以在空間和時間之間權衡以實現功能。

如果您的具體類沒有實現所有的功能,它會再次變得抽象,因爲您有一個思想或想法或抽象的實現,但它不完整,您可以通過abstract類指定它。

一個具體的類將是一個類/一組類,它將完全捕獲你試圖捕獲類XYZ的抽象性。

所以圖案是

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

這個答案根本不回答我的問題。另外'''它接縫就像你是Java新手'。真的嗎? –

+0

「abstract is obsolete」 – Manish

+0

(1)「abstract is obsolete」 - >如果他們刪除它並且編譯器停止識別它,那麼以前版本的源代碼使用「抽象接口」不會在新版本中編譯..他們需要保持向後兼容性。當你定義抽象接口時,接口關鍵字的含義與它一起被「卡住」,這對於他們提供的有經驗的程序員快捷鍵「界面」..你的問題是類似於我= i + 1 ==>我++ ..選擇是你的你選擇的:D – Manish