首页 > 代码库 > 是否存在不继承自System.Object类型的类

是否存在不继承自System.Object类型的类

分析问题

  可能读者的固有思维认为.NET中所有的类型都必须继承自System.Object,这样的认识过于绝对,且不完全正确。在.NET中,.NET设计小组为中间语言的编译器ILasm.exe添加了noautoinherit开关,当这个开关被打开时,编译器将不会默认年地把类型认为继承自System.Object。

  首先介绍一下中间语言的编译工具:ILasm.exe。这是.NET Framework提供的一个编译工具,它的作用是把中间语言(MSIL)编译成可执行的PE文件。该工具非常有用,它不仅使程序员有机会能够直接编写中间语言并且编译成PE文件,而且提供了另外一种部署方式,即手动地编译所有的中间代码并且直接部署最终的机器代码。

  如果程序员用的开发语言是C#,则在编译成中间语言时,类型已经被默认地添加了继承自System.Object的代码,这时候无论是否为ILasm.exe打开noautoinherit开关,生成的类型都将继承自System.Object,但如果程序员手动地编写了不继承自System.Object类型的中间代码,并且使用noautoinherit开关,则会生成一个特别的无父类的类型。

  在全托管单语言的编程环境下,设计不继承自System.Object的类型不会带来任何好处,相反地,它会导致种种违反常规的运行错误。不继承自System.Object的类型不符合CLS的规范,并且在正常的程序中出现意外的异常。但是为了融合其他编程语言(比如C++/CLI),这样的内建机制有着其独特的作用。在通常情况下,读者不需要也不应该建立不继承自System.Object的类型,但需要注意的是,在特殊的环境下任何代码不能作出对象类型继承自System.Object的保证,甚至于不能相信as、is等类型检查语法的结果。程序员唯一可以并且必须做得就是:时刻准备着捕捉各种意料之外的异常。

答案

  通过运用ILasm.exe的noautoinherit开关,可以生成不从System.Object继承的类型,这种类型不是安全的类型,也不建议使用。但是,这样机制的存在,促使程序员在编写代码时不能随意地把任何对象默认地看成System.Object的子类类型。