CLR对象可以继承另一个对象，可以继承N多个接口。

所有的对象都有根继承对象Sytem.Object，但它可以继承多个接口。接口和对象仍然是本质上不同的东西。
 

支持(0) 反对(0)

@xiao_p 
哈哈，老赵一般都比较晚，我很少这么晚，那是因为我没他那么牛，所以不敢晚睡:-)

支持(0) 反对(0)

天呀，这么晚还不睡？牛人呀，我佩服！

支持(0) 反对(0)

@·风信子· 
非也非也，我在博客上所发表的只有全书内容的20%左右，所以大部分精彩的内容还得到书上寻找答案。 

从第20回起发表的系列文章，在书中并未包括，我将其戏称为“必须的2.0”，这些新内容将考虑在后续《你必须知道的.NET》中出版。 

谢谢:-)

支持(0) 反对(0)

@李战 
老哥，近来很少见你冒泡了，常来呀:-P

支持(0) 反对(0)

@CoderZh 
--引用-------------------------------------------------- 
CoderZh: 刚到公司，惯例先浏览博客园的新文章。 
-------------------------------------------------------- 
好像是很多人的习惯

支持(0) 反对(0)

@海天一鸥 
诚如所言，接口确实存在诸多的不一样，本文论述的也算是特殊之一，但是在IL级别将接口看做class也未尝不可。

支持(0) 反对(0)

@落实 
一口气上五楼，不觉得累:-) 

写完才发现，好像比较晚了，好在时间没有太久:-)

支持(0) 反对(0)

@Anders Liu 
哈哈，是滴是滴，这也算“罪证”之一。

支持(0) 反对(0)

先留名在读 
一天睡几个小时呀，佩服

支持(0) 反对(0)

有时候也很矛盾啊，比如： 
IMyObject o = ... 
Type t = o.GetType(); 

如果我说，如果IMyObject没有定义GetType方法的话，为什么可以这样调用呢？我觉得从概念上，语言已经作了约定了，即任何对象都会继承Object，拥有Object的成员。 
那么，如果/noautoinherit了呢？我不知道啊，如果没人试试看的话只能我自己来了，赫赫…… 

支持(0) 反对(0)

我的理解是编译器做的手脚

同样的问题还出现在值类型、枚举这些东西身上

从定义上说，他们也都是派生自object的
 

支持(0) 反对(0)

@-brian- 
今天睡的比较少

支持(0) 反对(0)

@李战 
呵呵，我通常是一边吃早饭一边看 

//如果留言有表情，好像无法引用，是个bug吧？

支持(0) 反对(0)

@Jeffrey Zhao 

那么，如果/noautoinherit了呢？我不知道啊，如果没人试试看的话只能我自己来了，赫赫…… 
----------------- 
如果那样的话，一样可以调用GetType()方法的。我还是支持观点一，我一直都坚信，接口从本质上来说，是一个类。不过是一个特殊的类罢了

支持(0) 反对(0)

接口,是栈模板 
类(这里指类的实体部分),是堆模板 

如果有如下结构: 
//======== 
public interface I 
{ 
void call(); 
} 

public class C1 : I 
{ 

public void call() 
{ 

} 
} 
//======= 
当我们这样写时: 
C1 obj = new C1(); 
其实是完成了如下工作: 
I obj = new C1(); 

(1) I obj : 用接口初始化栈 
(2) new C1() : 用类实体初始化堆 
(3) = : 栈与堆关联 

//========== 
当然,很多时候我们常这样写 

public class C2 
{ 
public void call() 
{ 

} 
} 
//- 
C1 obj = new C1(); 

其实通常情况下,定义一个类,一定要有接口与实现两部份,只不过很多语言帮我们做了这样一件事,当定义一 

Class时,如果有的实现不是实现某个接口的定义,在使用时会为其提取一个接口,用于初始化栈 


接口,存在于栈中 
类(这里指类的实体部分),存在于堆中, 
他们分别处于两个世界中,沟通这两个世界的纽带就是指针. 

而NET中的interface与Class只不过是对这个基本关系进行了一个包装

支持(0) 反对(0)

@Jeffrey Zhao 
-------------------------- 
IMyObject o = new LaoZhao(); 
Type t = o.GetType(); 
-------------------------- 
哈哈，这一点不奇怪，因为为o实例化的类型（例如LaoZhao）同时隐式继承于object，所以以o访问GetType是没有任何问题的，而且返回的应该是类型LaoZhao。 

关于/noautoinherit情况，试完告诉我:-) 

 

支持(0) 反对(0)

interface A
{
void Do();
}

class B : A
{
public void Do() { }
}

class Test
{
static void Main()
{
A a = new B();
a.ToString();
A.Equals(null,null);
Console.Read();
}
}
a.ToString();A.Equals(null,null);能调用都是为了圆‘一切继承自Object’吧，即使接口不继承自Object，也能做成像继承Object（其实把A.Equals(null,null)编译成call bool [mscorlib]System.Object::Equals(object,object)）

但下面就有些迷惑了：
!dumpclass 009813b8
Class Name: A
mdToken: 02000002 (C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\ph\ph\bin\Debug\ph.exe)
Parent Class: 790c3ef0
Module: 00982c5c
Method Table: 00983094
Vtable Slots: 1
Total Method Slots: 1
Class Attributes: a0 Interface, Abstract, 
NumInstanceFields: 0
NumStaticFields: 0

!dumpclass 790c3ef0
Class Name: System.Object
mdToken: 02000002 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Parent Class: 00000000
Module: 790c1000
Method Table: 79330508
Vtable Slots: 4
Total Method Slots: a
Class Attributes: 102001 
NumInstanceFields: 0
NumStaticFields: 0

能看出来A的父类Parent Class: 790c3ef0是Object，这个是为啥，也是为了圆’一切都继承Object'？
呵呵

支持(0) 反对(0)

@Anytao 
但是接口引用的对象，应该只能访问到接口的成员吧，从概念上讲。 
编译器在这方面就是在搞“默认”了。

支持(0) 反对(0)

@徐少侠 
编译器将将IObjectable.Equals()翻译为Object.Equals()，是编译器做的小小手脚，而IObjectable是否继承于Object，则是“与生俱来”的。

支持(0) 反对(0)

用户自定义类型默认是继承object的，只不过编译器隐式的为我们写好了。

第二点 就是刚刚提到的 interface 不继承object 可不可以认为 interface 和object 都是用户类型的基类 .而唯一的区别在于object 提供几个方法让子类去实现。

支持(0) 反对(0)

@麒麟.NET 
可以通知dudu，help了

支持(0) 反对(0)

写的比较易懂,看好你出《你必须知道的.NET》续. 

支持(0) 反对(0)

@飞林沙 
--引用-------------------------------------------------- 
飞林沙: @Jeffrey Zhao 

那么，如果/noautoinherit了呢？我不知道啊，如果没人试试看的话只能我自己来了，赫赫…… 
----------------- 
如果那样的话，一样可以调用GetType()方法的。我还是支持观点一，我一直都坚信，接口从本质上来说，是一个类。不过是一个特殊的类罢了 
-------------------------------------------------------- 
我想文中已经有明确的解释和说明了

支持(0) 反对(0)

--引用-------------------------------------------------- 
飞林沙: @Jeffrey Zhao 

那么，如果/noautoinherit了呢？我不知道啊，如果没人试试看的话只能我自己来了，赫赫…… 
----------------- 
如果那样的话，一样可以调用GetType()方法的。我还是支持观点一，我一直都坚信，接口从本质上来说，是一个类。不过是一个特殊的类罢了 
-------------------------------------------------------- 
那就怪了，如果noautoinherit，则说明类不默认继承Object，那么GetType()从哪里来？

支持(0) 反对(0)

@WXWinter(冬) 
说得很精彩，不过是很多“障眼法”迷失了眼睛罢了。

支持(0) 反对(0)

--引用--------------------------------------------------
Jeffrey Zhao: --引用--------------------------------------------------
飞林沙: @Jeffrey Zhao

那么，如果/noautoinherit了呢？我不知道啊，如果没人试试看的话只能我自己来了，赫赫…… 
-----------------
如果那样的话，一样可以调用GetType()方法的。我还是支持观点一，我一直都坚信，接口从本质上来说，是一个类。不过是一个特殊的类罢了
--------------------------------------------------------
那就怪了，如果noautoinherit，则说明类不默认继承Object，那么GetType()从哪里来？
----------------------------------------------------------引用--------------------------------------------------
Jeffrey Zhao: --引用--------------------------------------------------
飞林沙: @Jeffrey Zhao

那么，如果/noautoinherit了呢？我不知道啊，如果没人试试看的话只能我自己来了，赫赫…… 
-----------------
如果那样的话，一样可以调用GetType()方法的。我还是支持观点一，我一直都坚信，接口从本质上来说，是一个类。不过是一个特殊的类罢了
--------------------------------------------------------
那就怪了，如果noautoinherit，则说明类不默认继承Object，那么GetType()从哪里来？
--------------------------------------------------------
应该还是从object 来

支持(0) 反对(0)

@BZZ 
好吧，看上去大家还是在猜……过一会儿我自己去试试看

支持(0) 反对(0)

是不是也可以这样说，如果interface继承自Object，就无法实现多重继承了？

支持(0) 反对(0)

@红泥 
需要一点探索和思考~~~

支持(0) 反对(0)

@BZZ 
--引用-------------------------------------------------- 
BZZ: 用户自定义类型默认是继承object的，只不过编译器隐式的为我们写好了。 

第二点 就是刚刚提到的 interface 不继承object 可不可以认为 interface 和object 都是用户类型的基类 .而唯一的区别在于object 提供几个方法让子类去实现。 
-------------------------------------------------------- 
呵呵，这种说法我不敢贸然肯定，任何官方或者非官方都没有这么说过:-)

支持(0) 反对(0)

@凌军 
谢谢

支持(0) 反对(0)

@Jeffrey Zhao
老赵山寨我。。。。

支持(0) 反对(0)

IObjectable obj = new MyObject(); 

//Call Object instance methods 
obj.ToString(); 


虽然MyObject也继承Object,由于obj的类型是IObjectable类型,所以在这里怎么能调用ToString()方法呢. 
看完了整片文章,对这里还是新潮疑惑

支持(0) 反对(0)

从运行的情况看 
MyObject的Parent Class: 是System.Object，obj 可当做指针，在C#里它运行时是确定的(在C++里不确定，这就是CLR能使用GC的好处) 

但是如果把接口更改为： 
public abstract class IObjectable 
这样在运行时，MyObject的Parent Class是IObjectable，且Class Attributes: 为Abstract,。 
而IObjectable的Parent Class才是System.Object。 

所以接口这玩意规约于设计时。。与运行时无关。

支持(0) 反对(0)

强解

支持(0) 反对(0)

接口是不是可以看成这样的一个特殊“类”（在IL中，接口貌似类），它不仅有自己声明的方法，而且还把Object的所有方法声明“偷”过来了呢，因为任何implement接口的类，都直接或间接的extends了Object类。

支持(0) 反对(0)

好文啊

支持(0) 反对(0)

确实，我们似乎是应该对一些看似真理的东西，加以反思。 
凡事都要问一个为什么呢？

支持(0) 反对(0)

由于接口是由暴露给其它类型的项（方法、属性、事件）组成的描述符，所以接口本身不能提供这些项的实现，因此从定义上，它是一个抽象类型。在ILAsm中定义一个接口时，因为IL汇编器在遇到interface时会自动添加关键字abstract，所以可以省略关键字abstract。 
再说一个BT的概念，接口只可能为它的静态方法提供实现。就是说，在IL中，你可以写静态方法。我想，我这么说会雷倒一片人。

支持(0) 反对(0)

@重典 
怎么山寨的，我也想:-P

支持(0) 反对(0)

@我的地盘我做主 
呵呵，对于你提出的问题，需要一大篇长篇大论来解释，我已经计划在后续内容中，以3-4篇的内容来阐释清楚这个问题，届时再请来兄继续欣赏，何如？

支持(0) 反对(0)

@红泥 
@overred
我想这是对运行时分析的很好的补充:-P

@包建强 
好像谁也没雷着，详细参考：《Expert .NET 2.0 IL Assembler》 第七章 命名空间和类 

:-)

支持(0) 反对(0)

--引用-------------------------------------------------- 
包建强: 由于接口是由暴露给其它类型的项（方法、属性、事件）组成的描述符，所以接口本身不能提供这些项的实现，因此从定义上，它是一个抽象类型。在ILAsm中定义一个接口时，因为IL汇编器在遇到interface时会自动添加关键字abstract，所以可以省略关键字abstract。 
再说一个BT的概念，接口只可能为它的静态方法提供实现。就是说，在IL中，你可以写静态方法。我想，我这么说会雷倒一片人。 
-------------------------------------------------------- 
我已经雷倒了

支持(0) 反对(0)

--引用-------------------------------------------------- 
Anytao: @包建强 
好像谁也没雷着，详细参考：《Expert .NET 2.0 IL Assembler》 第七章 命名空间和类 

:-) 
-------------------------------------------------------- 
你骂我不是人 我bs你 亩哈哈

支持(0) 反对(0)

个人认为 既然是共性的oo思想 那么 .net il 对于interface 的特殊处理就不应该作为共性的接口认知的一部分。初学者看了这篇文章 对理解.net 以外的接口会产生很不好的作用。 

作为正统oo思想 接口不能独立于实例存在 而且理应不存在任何已经实现的方法和静态成员，接口的实例不应存在，接口的静态方法也不应该存在 

在这个帖子里我不小心听到了一些关于,net的风言风语 现在我决定把它忘记。 

亩哈哈

支持(0) 反对(0)

这个题目本来就是不成立的，因为在C#的概念中，接口不是类，接口不能被继承（只能被实现），接口也不能从一个类型继承。而C#的官方说法也是，所有类型都间接继承于System.Object，这里的主语是类型，而不是接口。 

一个接口可以扩展（进化）另一个接口，但没有继承于某一个类型的概念。 



所以这个问题的答案应该说，“接口” “不能” “继承”，这个命题不成立。

支持(0) 反对(0)

@Anytao 
呵呵,到时候我一定好好拜读你的佳作

支持(0) 反对(0)

妙文妙文！ 

接口定义可以理解为声明性的东西， 接口是不能直接被创建的，如下实际是创建了MyObject类的一个实例： 
IObjectable obj = new MyObject(); 

所以万物还是皆对象，不知是否可以如此理解

支持(0) 反对(0)

万物归宗System.Object。但Interface不是“物”，是契约，是规则，是虚的思想，不是实实在在的"物“。类似万有引力定律一样，是抽象出来的思想，不能归为物体。
OK，IObjectable obj = new MyObject(); 其实是实例化了一个继承自System.Object的具体对象，为啥？因为你用的是class MyObject。class关键字就表明了其肯定继承System.Object，是个实物。
而继承自IObjectable接口，仅仅是符合其契约和规则，符合协定的定律而已。照规矩办事，但规矩本身不是物，是抽象思维。
另外，interface关键字与class关键字代表的含义不同哦！你用class，默认继承System.Object。而用interface，你找不到System.Object痕迹。
因此，这个结论很简单：interface本身不继承System.Object，但其具体的实现（因为使用class关键字）肯定继承System.Object，也就是楼主的结论2。
大家想想：数学定律，万有引力定律等等能算“物”么？还是这些是客观存在的但没有任务物体附属的规律呢？

支持(0) 反对(0)

@非主流程序员 
赞

支持(0) 反对(0)

@韦恩卑鄙 
呵呵，我是在你之前说的，再说包子雷人是他的事儿，反正我没被雷:-) 

不过，我作证你是大大的好人。

支持(0) 反对(0)

@韦恩卑鄙 

--引用-------------------------------------------------- 
韦恩卑鄙: 个人认为 既然是共性的oo思想 那么 .net il 对于interface 的特殊处理就不应该作为共性的接口认知的一部分。初学者看了这篇文章 对理解.net 以外的接口会产生很不好的作用。 

作为正统oo思想 接口不能独立于实例存在 而且理应不存在任何已经实现的方法和静态成员，接口的实例不应存在，接口的静态方法也不应该存在 

在这个帖子里我不小心听到了一些关于,net的风言风语 现在我决定把它忘记。 

亩哈哈 
-------------------------------------------------------- 


事实上，对应接口不光是在IL层有特别的处理，其本质的定位上就是完全不同于普通类型的概念，所以对初学者有不好影响完全么必要，只要仔细看文章我想理解是很清楚的。 

另外，哪里有对.NET的风言风语呀:-)

支持(0) 反对(0)

@Ivony... 
首先这不是一个关于C#接口和类概念的清算贴，全文没有任何字眼和概念直言接口就是类，类也是接口，如果那样搞两个概念是完全没有必要的，而且事实上我们讨论的是基于.NET概念而言，阐述的也是通用类型系统的概念。 

如果对于“而C#的官方说法也是，所有类型都间接继承于System.Object，这里的主语是类型，而不是接口。 ”有所质疑。那么，首先需要了解接口是不是类型，我想官方定义可能更加权威，所以请不妨参照：http://msdn.microsoft.com/zh-cn/library/2hf02550(VS.80).aspx 

事实上，对于类型的分类和定位，可以有多个角度，其实在我看来CTS单纯以值类型和引用类型的二元分法有时不一定表达了最科学的角度，例如从大概念上分为值类型、引用类型、指针类型和接口类型也未尝不可。 

本文的意义在于什么呢？我想答案是，事实上很多身边的朋友都存在对这一问题的误区，也是我想写写想法的初衷，仅此而已。 
 

支持(0) 反对(0)

@我的地盘我做主 
谢谢

支持(0) 反对(0)

@Anders06 
我觉得，可以这么理解，而且很对。哈哈

支持(0) 反对(0)

@非主流程序员 
@Anders06 
表达同样的呼声：赞。

支持(0) 反对(0)

嗯，唯“物”主义还是站得住脚的:)

支持(0) 反对(0)

--引用-------------------------------------------------- 
Anytao: @韦恩卑鄙 

--引用-------------------------------------------------- 
韦恩卑鄙: 个人认为 既然是共性的oo思想 那么 .net il 对于interface 的特殊处理就不应该作为共性的接口认知的一部分。初学者看了这篇文章 对理解.net 以外的接口会产生很不好的作用。 

作为正统oo思想 接口不能独立于实例存在 而且理应不存在任何已经实现的方法和静态成员，接口的实例不应存在，接口的静态方法也不应该存在 

在这个帖子里我不小心听到了一些关于,net的风言风语 现在我决定把它忘记。 

亩哈哈 
-------------------------------------------------------- 


事实上，对应接口不光是在IL层有特别的处理，其本质的定位上就是完全不同于普通类型的概念，所以对初学者有不好影响完全么必要，只要仔细看文章我想理解是很清楚的。 

另外，哪里有对.NET的风言风语呀:-) 
-------------------------------------------------------- 

老包不是说interface 在il可以加入静态成员么 这么雷人的事情我尽量忘记他 恩恩 
 

支持(0) 反对(0)

@Anders Cui 
:-)

支持(0) 反对(0)

@韦恩卑鄙 
:-)

支持(0) 反对(0)

--引用-------------------------------------------------- 
Anytao: @Ivony... 

首先这不是一个关于C#接口和类概念的清算贴，全文没有任何字眼和概念直言接口就是类，类也是接口，如果那样搞两个概念是完全没有必要的，而且事实上我们讨论的是基于.NET概念而言，阐述的也是通用类型系统的概念。 



如果对于“而C#的官方说法也是，所有类型都间接继承于System.Object，这里的主语是类型，而不是接口。 ”有所质疑。那么，首先需要了解接口是不是类型，我想官方定义可能更加权威，所以请不妨参照：<a href="http://msdn.microsoft.com/zh-cn/library/2hf02550" target="_new">http://msdn.microsoft.com/zh-cn/library/2hf02550</a>(VS.80).aspx 



事实上，对于类型的分类和定位，可以有多个角度，其实在我看来CTS单纯以值类型和引用类型的二元分法有时不一定表达了最科学的角度，例如从大概念上分为值类型、引用类型、指针类型和接口类型也未尝不可。 



本文的意义在于什么呢？我想答案是，事实上很多身边的朋友都存在对这一问题的误区，也是我想写写想法的初衷，仅此而已。 




-------------------------------------------------------- 


事实上LZ已经在不知不觉中把这个问题给挖出来了，我只是进一步阐述罢了。 

我们证明一个命题之前，必须先将其中的概念明确。而在这个例子中，事实上继承这个概念就是不明确的，所以这个命题是没有意义的。 

这一点LZ已经在文章中挖出来了，只是自己没发现，引用文中一句话： 

“而以extends标识继承关系是IL代码告诉我们真相的最佳证明。” 


很好，如果我们定义extends标识了继承关系，那么继承接口是不是extends标识的呢？答案是否定的。 

这就出问题了，LZ在文中给我们提出了一个命题： 

“继承关系以extends标识“ 


如果这个命题是正确的，则接口永远不会出现在任何extends中，也不会extends任何别的东西（即使是“继承”于别的接口）。可以推论接口不能被任何东西“继承”也不能“继承”于任何东西。原命题“interface到底继承于object吗“就不成立了。 

如果这个命题是错误的，那么LZ的推论也就不成立了。 


所以要说明白“interface到底继承于object吗”，我们就一定要先厘清继承的定义。 

所以这个问题可以有N个答案，比如说： 


1、令“继承”即是指A类型对象可以直接被当作B类型对象处理，其中并无隐式类型转换，也未曾创建一个新的B类型的对象，而是用B类型来操作A类型对象，即称为A类型继承于B类型。 

从这个定义出发，接口的确继承于System.Object。就算实际上是实现接口的类型都继承于System.Object，但如果继承的定义仅从效果上来看待的话，那么接口的确继承于System.Object。 


其他的定义我就不探讨了。

支持(0) 反对(0)

《框架设计（第二版）：CLR Via C#》的P265-266：“此外，CLR还允许调用Object定义的方法，因为所有类都继承了Object的方法........此外，可以调用Object定义的任何一个方法（比如GetType），因为CLR知道所有类型都继承自Object。” 

由此可知，之所以出现这种现象，是CLR的支持，C#的约定。

支持(0) 反对(0)

C++里没有interface关键字，但同样完美实现了OO，而且有多继承。 
叫什么无所谓，我的理解其实interface就是C++的抽象类的一种特例。 
可以这么理解，抽象类可以实现接口的功能，但是反之不行，因为接口不能有实现代码，所以接口也其实就是只含有定义的抽象类。 
不知道这么说合适不？

支持(0) 反对(0)

--引用--------------------------------------------------
我的地盘我做主: IObjectable obj = new MyObject();

//Call Object instance methods
obj.ToString();


虽然MyObject也继承Object,由于obj的类型是IObjectable类型,所以在这里怎么能调用ToString()方法呢.
看完了整片文章,对这里还是新潮疑惑
--------------------------------------------------------
这个时候，obj的类型并不是IObjectable，而是MyObject，IObjectable写在前面只是代表obj是一个实现了这个接口的类的实例。接口是不能实例化的。

支持(0) 反对(0)

--引用--------------------------------------------------
DiggingDeeply: C++里没有interface关键字，但同样完美实现了OO，而且有多继承。
叫什么无所谓，我的理解其实interface就是C++的抽象类的一种特例。
可以这么理解，抽象类可以实现接口的功能，但是反之不行，因为接口不能有实现代码，所以接口也其实就是只含有定义的抽象类。
不知道这么说合适不？
--------------------------------------------------------
支持你这种说法

支持(0) 反对(0)

继承就是extends,实现就是implements.
继承就是继承,实现就是实现，索性清楚一点多好吗
直接搬用java代码，嘿嘿

 

支持(0) 反对(0)

距离你出书已经有两年了，现在才来看你文章！会努力的学习，楼主V5.

支持(0) 反对(0)

多年以后，回头来看，或许，这三行代码可以说明问题。
Type type = typeof(IDisposable);
Console.WriteLine(type.BaseType);
Console.WriteLine(type.IsSubclassOf(typeof(Object)));