抽象類與接口之間的區(qū)別

1、本頁已使用福昕閱讀器進行編輯。福昕軟件(C2005-2010,版權所有,僅供試用。談抽象類與接口的區(qū)別之一一、抽象類:抽象類是特殊的類,只是不能被實例化;除此以外,具有類的其他特性;重要的是抽象類可以包括抽象方法,這是普通類所不能的。抽象方法只能聲明于抽象類中,且不包含任何實現(xiàn),派生類必須覆蓋它們。另外,抽象類可以派生自一個抽象類,可以覆蓋基類的抽象方法也可以不覆蓋,如果不覆蓋,則其派生類必須覆蓋它們。二、接口:接口是引用類型的,類似于類,和抽象類的相似之處有三點:1、不能實例化;2、包含未實現(xiàn)的方法聲明;3、派生類必須實現(xiàn)未實現(xiàn)的方法,抽象類是抽象方法,接口則是所有成員(不僅是方法包括其他成

2、員;另外,接口有如下特性:接口除了可以包含方法之外,還可以包含屬性、索引器、事件,而且這些成員都被定義為公有的。除此之外,不能包含任何其他的成員,例如:常量、域、構造函數(shù)、析構函數(shù)、靜態(tài)成員。一個類可以直接繼承多個接口,但只能直接繼承一個類(包括抽象類。三、抽象類和接口的區(qū)別:1.類是對對象的抽象,可以把抽象類理解為把類當作對象,抽象成的類叫做抽象類.而接口只是一個行為的規(guī)范或規(guī)定,微軟的自定義接口總是后帶able字段,證明其是表述一類類“我能做?！?類間,而接口大多數(shù)是關系疏松但都實現(xiàn)某一功能的類中.2.接口基本上不具備繼承的任何具體特點,它僅僅承諾了能夠調(diào)用的方法;3.一個類一次可以實現(xiàn)若

3、干個接口,但是只能擴展一個父類4.接口可以用于支持回調(diào),而繼承并不具備這個特點.5.抽象類不能被密封。6.抽象類實現(xiàn)的具體方法默認為虛的,但實現(xiàn)接口的類中的接口方法卻默認為非虛的,當然您也可以聲明為虛的.7.(接口與非抽象類類似,抽象類也必須為在該類的基類列表中列出的接口的所有成員提供它自己的實現(xiàn)。但是,允許抽象類將接口方法映射到抽象方法上。8.抽象類實現(xiàn)了oop中的一個原則,把可變的與不可變的分離。抽象類和接口就是定義為不可變的,而把可變的座位子類去實現(xiàn)。9.好的接口定義應該是具有專一功能性的,而不是多功能的,否則造成接口污染。如果一個類只是實現(xiàn)了這個接口的中一個功能,而不得不去實現(xiàn)接口中的

4、其他方法,就叫接口污染。10.盡量避免使用繼承來實現(xiàn)組建功能,而是使用黑箱復用,即對象組合。因為繼承的層次增多,造成最直接的后果就是當你調(diào)用這個類群中某一類,就必須把他們?nèi)考虞d到棧中!后果可想而知.(結合堆棧原理理解。同時,有心的朋友可以留意到微軟在構建一個類時,很多時候用到了對象組合的方法。比如中,Page類,有Server Request等屬性,但其實他們都是某個類的對象。使用Page類的這個對象來調(diào)用另外的類的方法和屬性,這個是非?；镜囊粋€設計原則。11.如果抽象類實現(xiàn)接口,則可以把接口中方法映射到抽象類中作為抽象方法而不必實現(xiàn),而在抽象類的子類中實現(xiàn)接口中方法.四、抽象類和接口的使

5、用:1. 如果預計要創(chuàng)建組件的多個版本,則創(chuàng)建抽象類。抽象類提供簡單的方法來控制組件版本。2.如果創(chuàng)建的功能將在大范圍的全異對象間使用,則使用接口。如果要設計小而簡練的功能塊,則使用接口。3.如果要設計大的功能單元,則使用抽象類.如果要在組件的所有實現(xiàn)間提供通用的已實現(xiàn)功能,則使用抽象類。4.抽象類主要用于關系密切的對象;而接口適合為不相關的類提供通用功能。以下是我在網(wǎng)上看到的幾個形象比喻,真的非常不錯,呵呵:1.飛機會飛,鳥會飛,他們都繼承了同一個接口“飛”;但是F22屬于飛機抽象類,鴿子屬于鳥抽象類。2. 就像鐵門木門都是門(抽象類,你想要個門我給不了(不能實例化,但我可以給你個具體的鐵門

6、或木門(多態(tài);而且只能是門,你不能說它是窗(單繼承;一個門可以有鎖(接口也可以有門鈴(多實現(xiàn)。門(抽象類定義了你是什么,接口(鎖規(guī)定了你能做什么(一個接口最好只能做一件事,你不能要求鎖也能發(fā)出聲音吧(接口污染 談抽象類與接口的區(qū)別之二abstract class和interface是Java語言中對于抽象類定義進行支持的兩種機制,正是由于這兩種機制的存在,才賦予了Java強大的面向?qū)ο竽芰Αbstract class和interface之間在對于抽象類定義的支持方面具有很大的相似性,甚至可以相互替換,因此很多開發(fā)者在進行抽象類定義時對于abstract class和interface的選擇顯

7、得比較隨意。其實,兩者之間還是有很大的區(qū)別的,對于它們的選擇甚至反映出對于問題領域本質(zhì)的理解、對于設計意圖的理解是否正確、合理。本文將對它們之間的區(qū)別進行一番剖析,試圖給開發(fā)者提供一個在二者之間進行選擇的依據(jù)。 一、理解抽象類abstract class和interface在Java語言中都是用來進行抽象類(本文中的抽象類并非從abstract class翻譯而來,它表示的是一個抽象體,而abstract class為Java語言中用于定義抽象類的一種方法,請讀者注意區(qū)分定義的,那么什么是抽象類,使用抽象類能為我們帶來什么好處呢?在面向?qū)ο蟮母拍钪?我們知道所有的對象都是通過類來描繪的,但是反

8、過來卻不是這樣。并不是所有的類都是用來描繪對象的,如果一個類中沒有包含足夠的信息來描繪一個具體的對象,這樣的類就是抽象類。抽象類往往用來表征我們在對問題領域進行分析、設計中得出的抽象概念,是對一系列看上去不同,但是本質(zhì)上相同的具體概念的抽象。比如:如果我們進行一個圖形編輯軟件的開發(fā),就會發(fā)現(xiàn)問題領域存在著圓、三角形這樣一些具體概念,它們是不同的,但是它們又都屬于形狀這樣一個概念,形狀這個概念在問題領域是不存在的,它就是一個抽象概念。正是因為抽象的概念在問題領域沒有對應的具體概念,所以用以表征抽象概念的抽象類是不能夠?qū)嵗摹Ｔ诿嫦驅(qū)ο箢I域,抽象類主要用來進行類型隱藏。我們可以構造出一個固定的一

9、組行為的抽象描述,但是這組行為卻能夠有任意個可能的具體實現(xiàn)方式。這個抽象描述就是抽象類,而這一組任意個可能的具體實現(xiàn)則表現(xiàn)為所有可能的派生類。模塊可以操作一個抽象體。由于模塊依賴于一個固定的抽象體,因此它可以是不允許修改的;同時,通過從這個抽象體派生,也可擴展此模塊的行為功能。熟悉OCP的讀者一定知道,為了能夠?qū)崿F(xiàn)面向?qū)ο笤O計的一個最核心的原則OCP(Open-Closed Principle,抽象類是其中的關鍵所在。二、從語法定義層面看abstract class和interface在語法層面,Java語言對于abstract class和interface給出了不同的定義方式,下面以定義一

10、個名為Demo的抽象類為例來說明這種不同。使用abstract class的方式定義Demo抽象類的方式如下:abstract class Demo abstract void method1(;abstract void method2(;使用interface的方式定義Demo抽象類的方式如下:interface Demo void method1(;void method2(;在abstract class方式中,Demo可以有自己的數(shù)據(jù)成員,也可以有非abstarct的成員方法,而在interface方式的實現(xiàn)中,Demo只能夠有靜態(tài)的不能被修改的數(shù)據(jù)成員(也就是必須是static f

11、inal的,不過在interface中一般不定義數(shù)據(jù)成員,所有的成員方法都是abstract的。從某種意義上說,interface是一種特殊形式的abstract class。從編程的角度來看,abstract class和interface都可以用來實現(xiàn)"design by contract"的思想。但是在具體的使用上面還是有一些區(qū)別的。首先,abstract class在Java語言中表示的是一種繼承關系,一個類只能使用一次繼承關系。但是,一個類卻可以實現(xiàn)多個interface。也許,這是Java語言的設計者在考慮Java對于多重繼承的支持方面的一種折中考慮吧。其次,在

12、abstract class的定義中,我們可以賦予方法的默認行為。但是在interface的定義中,方法卻不能擁有默認行為,為了繞過這個限制,必須使用委托,但是這會增加一些復雜性,有時會造成很大的麻煩。在抽象類中不能定義默認行為還存在另一個比較嚴重的問題,那就是可能會造成維護上的麻煩。因為如果后來想修改類的界面(一般通過abstract class或者interface來表示以適應新的情況(比如,添加新的方法或者給已用的方法中添加新的參數(shù)時,就會非常的麻煩,可能要花費很多的時間(對于派生類很多的情況,尤為如此。但是如果界面是通過abstract class來實現(xiàn)的,那么可能就只需要修改定義在a

13、bstract class中的默認行為就可以了。同樣,如果不能在抽象類中定義默認行為,就會導致同樣的方法實現(xiàn)出現(xiàn)在該抽象類的每一個派生類中,違反了"one rule,one place" 時要非常的小心。三、從設計理念層面看abstract class和interface上面主要從語法定義和編程的角度論述了abstract class和interface的區(qū)別,這些層面的區(qū)別是比較低層次的、非本質(zhì)的。本文將從另一個層面:abstract class和interface所反映出的設計理念,來分析一下二者的區(qū)別。作者認為,從這個層面進行分析才能理解二者概念的本質(zhì)所在。前面已經(jīng)提

14、到過,abstarct class在Java語言中體現(xiàn)了一種繼承關系,要想使得繼承關系合理,父類和派生類之間必須存在"is a"關系,即父類和派生類在概念本質(zhì)上應該是相同的。對于interface 來說則不然,并不要求interface的實現(xiàn)者和interface定義在概念本質(zhì)上是一致的,僅僅是實現(xiàn)了interface定義的契約而已。為了使論述便于理解,下面將通過一個簡單的實例進行說明?？紤]這樣一個例子,假設在我們的問題領域中有一個關于Door的抽象概念,該Door具有執(zhí)行兩個動作open和close,此時我們可以通過abstract class或者interface來定義

15、一個表示該抽象概念的類型,定義方式分別如下所示:使用abstract class方式定義Door:abstract class Door abstract void open(;abstract void close(;使用interface方式定義Door:interface Door void open(;void close(;其他具體的Door類型可以extends使用abstract class方式定義的Door或者implements使用interface方式定義的Door?？雌饋砗孟袷褂胊bstract class和interface沒有大的區(qū)別。如果現(xiàn)在要求Door還要具有報警

16、的功能。我們該如何設計針對該例子的類結構呢(在本例中,主要是為了展示abstract class和interface反映在設計理念上的區(qū)別,其他方面無關的問題都做了簡化或者忽略下面將羅列出可能的解決方案,并從設計理念層面對這些不同的方案進行分析。解決方案一:簡單的在Door的定義中增加一個alarm方法,如下:abstract class Door abstract void open(;abstract void close(;abstract void alarm(;或者interface Door void open(;void close(;void alarm(;那么具有報警功能的A

17、larmDoor的定義方式如下:class AlarmDoor extends Door void open( void close( void alarm( 或者 class AlarmDoor implements Door void open( void close( void alarm( 這種方法違反了面向?qū)ο笤O計中的一個核心原則 ISP（Interface Segregation Priciple），在 Door 的定義中把 Door 概念本身固有的行為方法和另外一個概念"報警器"的行為方法混在了一起。這樣引起的一個問題是那些僅僅 依賴于 Door 這個概念的模

18、塊會因為"報警器"這個概念的改變（比如：修改 alarm 方法的參數(shù)）而改變，反之依然。 解決方案二： 既然 open、 close 和 alarm 屬于兩個不同的概念， 根據(jù) ISP 原則應該把它 們分別定義在代表這兩個概念的抽象類中。 定義方式有： 這兩個概念都使用 abstract class 方式定義； 兩個概念都使用 interface 方式定義； 一個概念使用 abstract class 方式定義，另一個概念使用 interface 方式定義。 顯然，由于 Java 語言不支持多重繼承，所以兩個概念都使用 abstract class 方式定義是不可行的。后面

19、兩種方式都是 可行的，但是對于它們的選擇卻反映出對于問題領域中的概念本質(zhì)的理解、對于設計意圖的反映是否正確、合理。我們 一一來分析、說明。 如果兩個概念都使用 interface 方式來定義，那么就反映出兩個問題： 1、我們可能沒有理解清楚問題領域，AlarmDoor 在概念本質(zhì)上到底是 Door 還是報警器？ 2、 如果我們對于問題領域的理解沒有問題， 比如： 我們通過對于問題領域的分析發(fā)現(xiàn) AlarmDoor 在概念本質(zhì)上和 Door 是一致的，那么我們在實現(xiàn)時就沒有能夠正確的揭示我們的設計意圖，因為在這兩個概念的定義上（均使用 interface 方式定義）反映不出上述含義。 如果我們對于問題領域的理解是： AlarmDoor 在概念本質(zhì)上是 Door， 時它有具有報警的功能。 同 我們該如何來設計、 實現(xiàn)來明確的反映出我們的意思呢？前面已經(jīng)說過，abstract class 在 Java 語言中表示一種繼承關系，而繼承關系在 本質(zhì)上是"is a"關系。所以對于 Door 這個概念，