程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> 關於.NET >> [你必須知道的.NET]第二十七回:interface到底繼承於object嗎?

[你必須知道的.NET]第二十七回:interface到底繼承於object嗎?

編輯:關於.NET

說在,開篇之前

在.NET世界裡,我們常常聽到的一句話莫過於“System.Object是一切類型的根,是所有類型的父類”,以至於我在《你必須知道的.NET》8.1節 以“萬物歸宗:System.Object”這樣的title為System.Object授予至高榮譽。所以,基於這樣的觀點就有了下面這句“接口是否也繼承於System.Object?”,事實上這正是今天在技術群裡小小討論的一個插曲。  

1 緣起

在.NET世界裡,我們常常聽到的一句話莫過於“System.Object是一切類型的根,是所有類型的父類”,以至於我在《你必須知道的.NET》8.1節 以“萬物歸宗:System.Object”這樣的title為System.Object授予至高榮譽。所以,基於這樣的觀點就有了下面這句“接口是否也繼承於System.Object?”,事實上這正是今天在技術群裡小小討論的一個插曲。

持“interface也繼承於object”,是基於以下的兩個觀點推斷的:

觀點一:

接口本質上也是一個class,因為接口類型編譯之後在IL中被標識為.class,既然是類那麼不可避免的最終繼承於System.Object。

觀點二:

假如有如下的接口和實現接口的類型:

// Release : code01, 2009/03/04
// Author : Anytao, http://www.anytao.com
// List  : IObjectable.cs
public interface IObjectable
{
}

// Release : code02, 2009/03/04
// Author : Anytao, http://www.anytao.com
// List  : MyObject.cs
public class MyObject : IObjectable
{
}

那麼,對於IObjectable對象而言,下面的調用是可行的:

// Release : code03, 2009/03/04
// Author : Anytao, http://www.anytao.com
// List  : Program.cs
class Program
{
   static void Main(string[] args)
   {
     IObjectable obj = new MyObject();

     //Call Object instance methods
     obj.ToString();
     //Call Object static methods
     IObjectable.Equals(null, null);
   }
}

顯然,IObjectable類型變量obj可以訪問存在於System.Object中的實例方法ToString()和虛方法Equals,當然其他的幾個公共服務也不例外:GetType()、Equals()、GetHashcode()、ReferenceEquals(),也可以由此推斷interface可訪問Object方法的蛛絲馬跡。

不可否認,以上觀點的部分推理是完全正確的,但是卻遺憾的導致了錯誤的答案,所以在本文中我將明確的找出:interface不繼承於object的原因和原理。關於接口本質話題的深度討論,請參考《你必須知道的.NET》1.5 “玩轉接口”和7.4 “面向抽象編程:接口和抽象類”的詳細分析。

2 從面向對象尋找答案

為了找出接口繼承的原因,我想從接口存在的意義入手是最能夠說明問題的辦法?接口,就像面向對象設計中的精靈,為OO思想注入了靈魂和活力,接口突破了繼承在縱向上的擴展方向,在橫向給予對象以更靈活的支持機制。

接口,封裝了對於行為的抽象,定義了實現者必須遵守的契約。例如,實現了System.ICloneable接口的類型被賦予了“可以被拷貝”這樣的契約,實現了System.Collections.IEnumerable接口的類型被賦予了“可以被枚舉”這樣的契約,不同的接口定義了不同的契約,就像不同的法律約束了不同的行為。那麼接口應該賦予的契約至少在層次上保持相對的單純和統一,如果為所有接口都無一例外的賦予GetType()、Equals()、GetHashcode()、ReferenceEquals()還有ToString()這樣的契約,未免使得接口的純潔和統一變得無從談起,例如強迫任何實現了System.ICloneable接口的類型同時遵守其他的約定是對ICloneable本身的侮辱。

從接口單一原則延伸思考,一個包含雜七雜八的接口定義顯然不是interface應該具有的純正血統,對於深谙面向對象為何物的.NET設計者而言,這是不言而喻的問題。所以,我們從接口本身的職責和意義出發,決定interface不從System.Object繼承是完全正確的。

3 在IL探求究竟

再次應用強大的IL武器來探求事實的真相,我們以Reflector打開所有的.NET既有接口,例如IList、IEmumerable、ICollection,都會有個共同的發現那就是你找不到extends System.Object這樣的標識:

.class public interface abstract auto ansi ICloneable
{
   .custom instance void System.Runtime.InteropServices.ComVisibleAttribute::.ctor(bool) = { bool(true) }
   .method public hidebysig newslot abstract virtual instance object Clone() cil managed
   {
   }
}

自定義類型也是如此,我們看看IObjectable的IL反編譯定義:

.class public interface abstract auto ansi IObjectable
{
}

而以extends標識繼承關系是IL代碼告訴我們真相的最佳證明。

System.Object真是“萬物歸宗”嗎?

讓我們再次回眸一笑,把Object進行一番把玩,難道一切類型都得繼承自Object嗎?其實不然。以ILASM.exe進行IL代碼編譯時,有一個參數選項NOAUTOINHERIT,正如其解釋所描述的那樣:

/NOAUTOINHERIT Disable inheriting from System.Object by default

顯然NoAutoInherit選項提供了為.NET類型“去掉帽子”的作用,簡單言之就是,在未指定基類時,禁止類型自動從Object繼承。

我們可以玩兒一個翻來覆去的IL游戲,將我們本文開始的Anytao.Insidenet.InterfaceInside.exe控制台程序以ILDASM.exe工具Dump為IL代碼My.il,例如MyObject被反編譯為:

.class public auto ansi beforefieldinit Anytao.Insidenet.InterfaceInside.MyObject
     extends [mscorlib]System.Object
     implements Anytao.Insidenet.InterfaceInside.IObjectable
{
  .method public hidebysig specialname rtspecialname
      instance void .ctor() cil managed
  {
   // Code size    7 (0x7)
   .maxstack 8
   IL_0000: ldarg.0
   IL_0001: call    instance void [mscorlib]System.Object::.ctor()
   IL_0006: ret
  } // end of method MyObject::.ctor

} // end of class Anytao.Insidenet.InterfaceInside.MyObject

我們可以選擇刪除其中所有extends繼承的代碼,再以ILASM.exe對其進行noautoinherit編譯,並生成

ilasm /exe /output:noobject.exe /noautoinherit my.il

新生成的noobject.exe程序將沒有從object繼承,某種程度上打破了“萬物歸宗”的創奇,MyObject就像一個無根之木,飄搖在我機器的某個深處。

4 結論

interface不從object繼承,那麼足下高見呢?文章雖短,取一瓢飲之,暢也。

那麼,我們該如何回答本文開始對此質疑的兩種觀點呢?

回答觀點一:

接口本質上還是一個類,但是一個特殊的類,它的特殊性表現在諸多的方面,例如所有的方法和屬性都是抽象的、支持多繼承等等,既然特殊那就特殊到底,不繼承於任何的父類也是其中之一吧。

雖然這種解釋未免牽強,但是如前文所述回到接口本源的角度而言,卻是最好的解釋。

回答觀點二:

.NET一切類型都隱式繼承於System.Object,那麼對於實現了任何接口的類型而言,例如:

// Release : code02, 2009/03/04
// Author : Anytao, http://www.anytao.com
// List  : MyObject.cs
public class MyObject : IObjectable
{
}

其在本質上相當於:

// Release : code02, 2009/03/04
// Author : Anytao, http://www.anytao.com
// List  : MyObject.cs
public class MyObject : Object, IObjectable
{
}

所以對於MyObject實例obj而言,obj.ToString()實質是MyObject類繼承於object,而不代表接口IObjectable也繼承於object。那麼IObjectable.Equals()則是編譯器做了手腳,將IObjectable.Equals()翻譯為Object.Equals()所致(來自腦袋高論,表示熱烈感謝)。事實上,對於接口聲明類型的方法調用,在實現機制上完全不同於一般的直接方法調用和虛方法分派機制,我們將在後續篇幅中詳細討論這一更重要的話題。

好了,interface,想說愛你不容易,可能我們還會再次相遇,也敬請朋友們繼續關注:你必須知道的.NET。

文章來源:http://anytao.cnblogs.com/

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved