抽象類與接口是java語言中對抽象概念進行定義的兩種機制,正是由于他們的存在才賦予java強大的面向對象的能力。他們兩者之間對抽象概念的支持有很大的相似,甚至可以互換,但是也有區別。
一、抽象類
?????? 我們都知道在面向對象的領域一切都是對象,同時所有的對象都是通過類來描述的,但是并不是所有的類都是來描述對象的。如果一個類沒有足夠的信息來描述一個具體的對象,而需要其他具體的類來支撐它,那么這樣的類我們稱它為抽象類。比如new Animal(),我們都知道這個是產生一個動物Animal對象,但是這個Animal具體長成什么樣子我們并不知道,它沒有一個具體動物的概念,所以他就是一個抽象類,需要一個具體的動物,如狗、貓來對它進行特定的描述,我們才知道它長成啥樣。
??????在面向對象領域由于抽象的概念在問題領域沒有對應的具體概念,所以用以表征抽象概念的抽象類是不能實例化的。
??????同時,抽象類體現了數據抽象的思想,是實現多態的一種機制。它定義了一組抽象的方法,至于這組抽象方法的具體表現形式有派生類來實現。同時抽象類提供了繼承的概念,它的出發點就是為了繼承,否則它沒有存在的任何意義。所以說定義的抽象類一定是用來繼承的,同時在一個以抽象類為節點的繼承關系等級鏈中,葉子節點一定是具體的實現類。(不知這樣理解是否有錯!!!高手指點….)
??????在使用抽象類時需要注意幾點:
?????????1、抽象類不能被實例化,實例化的工作應該交由它的子類來完成,它只需要有一個引用即可。
?????????2、抽象方法必須由子類來進行重寫。
?????????3、只要包含一個抽象方法的抽象類,該方法必須要定義成抽象類,不管是否還包含有其他方法。
?????????4、抽象類中可以包含具體的方法,當然也可以不包含抽象方法。
?????????5、子類中的抽象方法不能與父類的抽象方法同名。
?????????6、abstract不能與final并列修飾同一個類。
?????????7、abstract 不能與private、static、final或native并列修飾同一個方法。、
??????實例:
??????定義一個抽象動物類Animal,提供抽象方法叫cry(),貓、狗都是動物類的子類,由于cry()為抽象方法,所以Cat、Dog必須要實現cry()方法。如下:
public abstract class Animal {
? ? public abstract void cry();
}
public class Cat extends Animal{
? ? @Override
? ? public void cry() {
? ? ? ? System.out.println("貓叫:喵喵...");
? ? }
}
public class Dog extends Animal{
? ? @Override
? ? public void cry() {
? ? ? ? System.out.println("狗叫:汪汪...");
? ? }
}
public class Test {
? ? public static void main(String[] args) {
? ? ? ? Animal a1 = new Cat();
? ? ? ? Animal a2 = new Dog();
? ? ? ? a1.cry();
? ? ? ? a2.cry();
? ? }
}
?創建抽象類和抽象方法非常有用,因為他們可以使類的抽象性明確起來,并告訴用戶和編譯器打算怎樣使用他們.抽象類還是有用的重構器,因為它們使我們可以很容易地將公共方法沿著繼承層次結構向上移動。(From:Think in java )
?二、接口
??????接口是一種比抽象類更加抽象的“類”。這里給“類”加引號是我找不到更好的詞來表示,但是我們要明確一點就是,接口本身就不是類,從我們不能實例化一個接口就可以看出。如new Runnable();肯定是錯誤的,我們只能new它的實現類。
??????接口是用來建立類與類之間的協議,它所提供的只是一種形式,而沒有具體的實現。同時實現該接口的實現類必須要實現該接口的所有方法,通過使用implements關鍵字,他表示該類在遵循某個或某組特定的接口,同時也表示著“interface只是它的外貌,但是現在需要聲明它是如何工作的”。
??????接口是抽象類的延伸,java了保證數據安全是不能多重繼承的,也就是說繼承只能存在一個父類,但是接口不同,一個類可以同時實現多個接口,不管這些接口之間有沒有關系,所以接口彌補了抽象類不能多重繼承的缺陷,但是推薦繼承和接口共同使用,因為這樣既可以保證數據安全性又可以實現多重繼承。
??????在使用接口過程中需要注意如下幾個問題:
?????????1、個Interface的方所有法訪問權限自動被聲明為public。確切的說只能為public,當然你可以顯示的聲明為protected、private,但是編譯會出錯!
?????????2、接口中可以定義“成員變量”,或者說是不可變的常量,因為接口中的“成員變量”會自動變為為public static final??梢酝ㄟ^類命名直接訪問:ImplementClass.name。
?????????3、接口中不存在實現的方法。
???? ??? 4、實現接口的非抽象類必須要實現該接口的所有方法。抽象類可以不用實現。
????? ? ?5、不能使用new操作符實例化一個接口,但可以聲明一個接口變量,該變量必須引用(refer to)一個實現該接口的類的對象。可以使用 instanceof 檢查一個對象是否實現了某個特定的接口。例如:if(anObject instanceof Comparable){}。
????? ? ?6、在實現多接口的時候一定要避免方法名的重復。
三、抽象類與接口的區別
??????盡管抽象類和接口之間存在較大的相同點,甚至有時候還可以互換,但這樣并不能彌補他們之間的差異之處。下面將從語法層次和設計層次兩個方面對抽象類和接口進行闡述。
?3.1語法層次
??????在語法層次,java語言對于抽象類和接口分別給出了不同的定義。下面已Demo類來說明他們之間的不同之處。
??????使用抽象類來實現:
public abstract class Demo {
? ? abstract void method1();
?????void method2(){
? ? ? ? //實現
? ? }
}
?使用接口來實現
interface Demo {
? ? void method1();
? ? void method2();
}
抽象類方式中,抽象類可以擁有任意范圍的成員數據,同時也可以擁有自己的非抽象方法,但是接口方式中,它僅能夠有靜態、不能修改的成員數據(但是我們一般是不會在接口中使用成員數據),同時它所有的方法都必須是抽象的。在某種程度上來說,接口是抽象類的特殊化。
??????對子類而言,它只能繼承一個抽象類(這是java為了數據安全而考慮的),但是卻可以實現多個接口。
3.2設計層次
??????上面只是從語法層次和編程角度來區分它們之間的關系,這些都是低層次的,要真正使用好抽象類和接口,我們就必須要從較高層次來區分了。只有從設計理念的角度才能看出它們的本質所在。一般來說他們存在如下三個不同點:
??????1、 抽象層次不同。抽象類是對類抽象,而接口是對行為的抽象。抽象類是對整個類整體進行抽象,包括屬性、行為,但是接口卻是對類局部(行為)進行抽象。
??????2、 跨域不同。抽象類所跨域的是具有相似特點的類,而接口卻可以跨域不同的類。我們知道抽象類是從子類中發現公共部分,然后泛化成抽象類,子類繼承該父類即可,但是接口不同。實現它的子類可以不存在任何關系,共同之處。例如貓、狗可以抽象成一個動物類抽象類,具備叫的方法。鳥、飛機可以實現飛Fly接口,具備飛的行為,這里我們總不能將鳥、飛機共用一個父類吧!所以說抽象類所體現的是一種繼承關系,要想使得繼承關系合理,父類和派生類之間必須存在"is-a" 關系,即父類和派生類在概念本質上應該是相同的。對于接口則不然,并不要求接口的實現者和接口定義在概念本質上是一致的, 僅僅是實現了接口定義的契約而已。
??????3、 設計層次不同。對于抽象類而言,它是自下而上來設計的,我們要先知道子類才能抽象出父類,而接口則不同,它根本就不需要知道子類的存在,只需要定義一個規則即可,至于什么子類、什么時候怎么實現它一概不知。比如我們只有一個貓類在這里,如果你這是就抽象成一個動物類,是不是設計有點兒過度?我們起碼要有兩個動物類,貓、狗在這里,我們在抽象他們的共同點形成動物抽象類吧!所以說抽象類往往都是通過重構而來的!但是接口就不同,比如說飛,我們根本就不知道會有什么東西來實現這個飛接口,怎么實現也不得而知,我們要做的就是事前定義好飛的行為接口。所以說抽象類是自底向上抽象而來的,接口是自頂向下設計出來的。
四、總結
??????1、 抽象類在java語言中所表示的是一種繼承關系,一個子類只能存在一個父類,但是可以存在多個接口。
??????2、 在抽象類中可以擁有自己的成員變量和非抽象類方法,但是接口中只能存在靜態的不可變的成員數據(不過一般都不在接口中定義成員數據),而且它的所有方法都是抽象的。
??????3、抽象類和接口所反映的設計理念是不同的,抽象類所代表的是“is-a”的關系,而接口所代表的是“like-a”的關系。
??????抽象類和接口是java語言中兩種不同的抽象概念,他們的存在對多態提供了非常好的支持,雖然他們之間存在很大的相似性。但是對于他們的選擇往往反應了您對問題域的理解。只有對問題域的本質有良好的理解,才能做出正確、合理的設計。