抽象類和接口的區別:
區別一,兩者表達的概念不一樣。抽象類是一類事物的高度聚合,那麼對於繼承抽象類的子類來說,對於抽象類來說,屬於“是”的關係;而接口是定義行爲規範,因此對於實現接口的子類來說,相對於接口來說,是“行爲需要按照接口來完成”。這些聽起來有些虛,舉個例子。例如,狗是對於所有狗類動物的統稱,京哈是狗,牧羊犬是狗,那麼狗的一般特性,都會在京哈,牧羊犬中找到,那麼狗相對於京哈和牧羊犬來說,就屬於這類事物的抽象類型;而對於“叫”這個動作來說,狗可以叫,鳥也可以叫。很明顯,前者相當於所說的是抽象類,而後者指的就是接口。
區別二,抽象類在定義類型方法的時候,可以給出方法的實現部分,也可以不給出;而對於接口來說,其中所定義的方法都不能給出實現部分。
例如:
public abstract class AbsTest
{
public virtual void Test()
{
Debug.WriteLine( "Test" );
}
public abstract void NewTest();
}
public interface ITest
{
void Test();
void NewTest();
}
區別三,繼承類對於兩者所涉及方法的實現是不同的。繼承類對於抽象類所定義的抽象方法,可以不用重寫,也就是說,可以延用抽象類的方法;而對於接口類所定義的方法或者屬性來說,在繼承類中必須要給出相應的方法和屬性實現。
區別四,在抽象類中,新增一個方法的話,繼承類中可以不用作任何處理;而對於接口來說,則需要修改繼承類,提供新定義的方法
知道了兩者的區別,再來說說,接口相對於抽象類的優勢。
好處一,接口不光可以作用於引用類型,也可以作用於值類型。而抽象類來說,只能作用於引用類型。
好處二,.Net的類型繼承只能是單繼承的,也就是說一個類型只能繼承一個類型,而可以繼承多個接口。其實,我對於這一點也比較贊同,多繼承會使繼承樹變的混亂。
好處三,由於接口只是定義屬性和方法,而與真正實現的類型沒有太大的關係,因此接口可以被多個類型重用。相對於此,抽象類與繼承類的關係更緊密些。
好處四,通過接口,可以減少類型暴露的屬性和方法,從而便於保護類型對象。當一個實現接口的類型,可能包含其他方法或者屬性,但是方法返回的時候,可以返回接口對象,這樣調用端,只能通過接口提供的方法或者屬性,訪問對象的相關元素,這樣可以有效保護對象的其他元素。
好處五,減少值類型的拆箱操作。對於Struct定義的值類型數據,當存放集合當中,每當取出來,都需要進行拆箱操作,這時採用Struct+Interface結合的方法,從而降低拆箱操作。
相對於抽象類來說,接口有這麼多好處,但是接口有一個致命的弱點,就是接口所定義的方法和屬性只能相對於繼承它的類型(除非在繼承類中修改藉口定義的函數標示),那麼對於多層繼承關係的時候,光用接口就很難實現。因爲如果讓每個類型都去繼承接口而進行實現的話,首先不說編寫代碼比較繁瑣,有時候執行的結果還是錯誤,尤其當子類型對象隱式轉換成基類對象進行訪問的時候。
那麼這時候,需要用接口結合虛方法來實現。
其實在繼承中,到底使用接口還是抽象類。接口是固定的,約定俗成的,因此在繼承類中必須提供接口相應的方法和屬性的實現。而對於抽象類來說,抽象類的定義方法的實現,貫穿整個繼承樹,因此其中方法的實現或者重寫都是不確定的。因此相對而言,抽象類比接口更靈活一些。
如下給出兩者的簡單對比表:
列1 | 接口 | |
多繼承 | 支持 | 不支持 |
類型限制 | 沒有 | 有,只能是引用類型 |
方法實現 | 繼承類型中必須給出方法實現 | 繼承類中可以不給出 |
擴展性 | 比較麻煩 | 相對比較靈活 |
多層繼承 | 比較麻煩,需要藉助虛函數 | 比較靈活 |
總的來說,接口和抽象類是.Net爲了更好的實現類型之間繼承關係而提供的語言手段,而且兩者有些相輔相成的關係。因此我並不強調用什麼而不用什麼,那麼問題的關鍵在於,如何把這兩種手段合理的應用到程序當中,這纔是至關重要。
該文章轉載自網絡大本營:http://www.xrss.cn/Dev/DotNet/200792016649.Html