關(guān)于interface繼承來源的討論
在.NET世界里，我們常常聽到的一句話莫過于“System.Object是一切類型的根，是所有類型的父類”，以至于我在《你必須知道的.NET》8.1節(jié) 以“萬物歸宗：System.Object”這樣的title為System.Object授予至高榮譽(yù)。所以，基于這樣的觀點(diǎn)就有了下面這句“接口是否也繼承于System.Object？”，事實(shí)上這正是今天在技術(shù)群里小小討論的一個(gè)插曲。
持“interface也繼承于object”，是基于以下的兩個(gè)觀點(diǎn)推斷的：
觀點(diǎn)一：
接口本質(zhì)上也是一個(gè)class，因?yàn)榻涌陬愋途幾g之后在IL中被標(biāo)識(shí)為.class，既然是類那么不可避免的最終繼承于System.Object。
觀點(diǎn)二：
假如有如下的接口和實(shí)現(xiàn)接口的類型：
- // Release : code01, 2009/03/04
- // Author : Anytao
- // List : IObjectable.cs
- public interface IObjectable
- {
- }// Release : code02, 2009/03/04
- // Author : Anytao
- // List : MyObject.cs
- public class MyObject : IObjectable
- {
- }
那么，對(duì)于IObjectable對(duì)象而言，下面的調(diào)用是可行的：
- // Release : code03, 2009/03/04
- // Author : Anytao
- // 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中的實(shí)例方法ToString()和虛方法Equals，當(dāng)然其他的幾個(gè)公共服務(wù)也不例外：GetType()、Equals()、GetHashcode()、ReferenceEquals()，也可以由此推斷interface可訪問Object方法的蛛絲馬跡。
不可否認(rèn)，以上觀點(diǎn)的部分推理是完全正確的，但是卻遺憾的導(dǎo)致了錯(cuò)誤的答案，所以在本文中我將明確的找出：interface不繼承于object的原因和原理。關(guān)于接口本質(zhì)話題的深度討論，請(qǐng)參考《你必須知道的.NET》1.5 “玩轉(zhuǎn)接口”和7.4 “面向抽象編程：接口和抽象類”的詳細(xì)分析。
2 從面向?qū)ο髮ふ掖鸢?/P>
為了找出接口繼承的原因，我想從接口存在的意義入手是最能夠說明問題的辦法？接口，就像面向?qū)ο笤O(shè)計(jì)中的精靈，為OO思想注入了靈魂和活力，接口突破了繼承在縱向上的擴(kuò)展方向，在橫向給予對(duì)象以更靈活的支持機(jī)制。
接口，封裝了對(duì)于行為的抽象，定義了實(shí)現(xiàn)者必須遵守的契約。例如，實(shí)現(xiàn)了System.ICloneable接口的類型被賦予了“可以被拷貝”這樣的契約，實(shí)現(xiàn)了System.Collections.IEnumerable接口的類型被賦予了“可以被枚舉”這樣的契約，不同的接口定義了不同的契約，就像不同的法律約束了不同的行為。那么接口應(yīng)該賦予的契約至少在層次上保持相對(duì)的單純和統(tǒng)一，如果為所有接口都無一例外的賦予GetType()、Equals()、GetHashcode()、ReferenceEquals()還有ToString()這樣的契約，未免使得接口的純潔和統(tǒng)一變得無從談起，例如強(qiáng)迫任何實(shí)現(xiàn)了System.ICloneable接口的類型同時(shí)遵守其他的約定是對(duì)ICloneable本身的侮辱。
從接口單一原則延伸思考，一個(gè)包含雜七雜八的接口定義顯然不是interface應(yīng)該具有的純正血統(tǒng)，對(duì)于深諳面向?qū)ο鬄楹挝锏?NET設(shè)計(jì)者而言，這是不言而喻的問題。所以，我們從接口本身的職責(zé)和意義出發(fā)，決定interface不從System.Object繼承是完全正確的。
3 在IL探求究竟
再次應(yīng)用強(qiáng)大的IL武器來探求事實(shí)的真相，我們以Reflector打開所有的.NET既有接口，例如IList、IEmumerable、ICollection，都會(huì)有個(gè)共同的發(fā)現(xiàn)那就是你找不到extends System.Object這樣的標(biāo)識(shí)：
- .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標(biāo)識(shí)繼承關(guān)系是IL代碼告訴我們真相的最佳證明。System.Object真是“萬物歸宗”嗎？
讓我們?cè)俅位仨恍Γ袿bject進(jìn)行一番把玩，難道一切類型都得繼承自O(shè)bject嗎？其實(shí)不然。以ILASM.exe進(jìn)行IL代碼編譯時(shí)，有一個(gè)參數(shù)選項(xiàng)NOAUTOINHERIT，正如其解釋所描述的那樣：
- /NOAUTOINHERIT Disable inheriting from System.Object by default
顯然NoAutoInherit選項(xiàng)提供了為.NET類型“去掉帽子”的作用，簡(jiǎn)單言之就是，在未指定基類時(shí)，禁止類型自動(dòng)從Object繼承。
我們可以玩兒一個(gè)翻來覆去的IL游戲，將我們本文開始的Anytao.Insidenet.InterfaceInside.exe控制臺(tái)程序以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對(duì)其進(jìn)行noautoinherit編譯，并生成
- ilasm /exe /output:noobject.exe /noautoinherit my.il
新生成的noobject.exe程序?qū)]有從object繼承，某種程度上打破了“萬物歸宗”的創(chuàng)奇，MyObject就像一個(gè)無根之木，飄搖在我機(jī)器的某個(gè)深處。
4 結(jié)論
interface不從object繼承，那么足下高見呢？文章雖短，取一瓢飲之，暢也。
那么，我們?cè)撊绾位卮鸨疚拈_始對(duì)此質(zhì)疑的兩種觀點(diǎn)呢？
回答觀點(diǎn)一：
接口本質(zhì)上還是一個(gè)類，但是一個(gè)特殊的類，它的特殊性表現(xiàn)在諸多的方面，例如所有的方法和屬性都是抽象的、支持多繼承等等，既然特殊那就特殊到底，不繼承于任何的父類也是其中之一吧。
雖然這種解釋未免牽強(qiáng)，但是如前文所述回到接口本源的角度而言，卻是最好的解釋。
回答觀點(diǎn)二：
.NET一切類型都隱式繼承于System.Object，那么對(duì)于實(shí)現(xiàn)了任何接口的類型而言，例如：
- // Release : code02, 2009/03/04
- // Author : Anytao
- // List : MyObject.cs
- public class MyObject : IObjectable
- {
- }
其在本質(zhì)上相當(dāng)于：
- // Release : code02, 2009/03/04
- // Author : Anytao
- // List : MyObject.cs
- public class MyObject : Object, IObjectable
- {
- }
所以對(duì)于MyObject實(shí)例obj而言，obj.ToString()實(shí)質(zhì)是MyObject類繼承于object，而不代表接口IObjectable也繼承于object。那么IObjectable.Equals()則是編譯器做了手腳，將IObjectable.Equals()翻譯為Object.Equals()所致（來自腦袋高論，表示熱烈感謝）。事實(shí)上，對(duì)于接口聲明類型的方法調(diào)用，在實(shí)現(xiàn)機(jī)制上完全不同于一般的直接方法調(diào)用和虛方法分派機(jī)制。
【編輯推薦】
