[你必须知道的.NET]第二十七回：interface到底继承于object吗？
发布日期：2009.03.05 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。
 说在，开篇之前 |
| 在.NET世界里，我们常常听到的一句话莫过于“System.Object是一切类型的根，是所有类型的父类”，以至于我在《你必须知道的.NET》8.1节 以“万物归宗：System.Object”这样的title为System.Object授予至高荣誉。所以，基于这样的观点就有了下面这句“接口是否也继承于System.Object？”，事实上这正是今天在技术群里小小讨论的一个插曲。 www.anytao.com |
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。
补充讨论：Leo Zhang，Interface到底继承于Object吗？之我见
2009/03/05 | http://anytao.cnblogs.com/ | http://www.cnblogs.com/anytao/archive/2009/03/05/must_net_27.html
本文以“现状”提供且没有任何担保，同时也没有授予任何权利。 | This posting is provided "AS IS" with no warranties, and confers no rights.
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
参考文献
- 《你必须知道的.NET》1.5 “玩转接口”
- 《你必须知道的.NET》7.4 “面向抽象编程：接口和抽象类”
- http://www.cnblogs.com/allenlooplee/archive/2007/01/22/627386.html
温故知新
[开篇有益]
[第一回：恩怨情仇：is和as]
[第二回：对抽象编程：接口和抽象类]
[第三回：历史纠葛：特性和属性]
[第四回：后来居上：class和struct]
[第五回：深入浅出关键字---把new说透]
[第六回：深入浅出关键字---base和this]
[第七回：品味类型---从通用类型系统开始]
[第八回：品味类型---值类型与引用类型（上）－内存有理]
[第九回：品味类型---值类型与引用类型（中）－规则无边]
[第十回：品味类型---值类型与引用类型（下）－应用征途]
[第十一回：参数之惑---传递的艺术（上）]
[第十二回：参数之惑---传递的艺术（下）]
[第十三回：从Hello, world开始认识IL]
[第十四回：认识IL代码---从开始到现在]
[第十五回：继承本质论]
[第十六回：深入浅出关键字---using全接触]
[第十七回：貌合神离：覆写和重载]
[第十八回：对象创建始末（上）]
[第十九回：对象创建始末（下）]
[第二十回：学习方法论]
[第二十一回：认识全面的null]
[第二十二回：字符串驻留（上）---带着问题思考]
[第二十三回：品味细节，深入.NET的类型构造器]
[第二十四回：认识元数据和IL（上）]
[第二十五回：认识元数据和IL（中）]
[第二十六回：认识元数据和IL（下）]