请帮助我们解决“几乎”一切都是对象(an answer to Stack Overflow question )的争议。我认为情况就是这样,因为Visual Studio中的所有东西至少看起来都是一个结构。请发一个推荐信,这样它就不会变成“现代笨蛋”(This American Life)了。
请注意,这个问题指的是C#,而不一定是.NET,以及它如何在幕后处理数据(显然都是1和0)。
下面是对“一切都是对象”的评论:
对象的定义:"Object“作为类System.Object的继承者,"object”作为类型的实例,"object“作为引用类型。”
发布于 2009-01-12 17:29:54
这里的问题是,这实际上是两个问题-一个问题是关于继承,在这种情况下,答案是“几乎一切”,另一个是关于引用类型与值类型/内存/装箱,在这种情况下,答案是“否”。
继承:
在C#中,以下情况成立:
System.Object
派生的。所有类、数组和委托类型都派生自System.Object
.System.Object
,但接口只能派生自其他接口类型,而System.Object
不是接口类型。没有从System.Object
派生的指针类型,也不能直接转换为System.Object
.System.Object
派生的。类型参数类型不是从任何东西派生的;类型参数被约束为从有效的基类派生,但它们本身并不是从任何东西“派生”的。来自the MSDN entry for System.Object
支持.NET框架类层次结构中的所有类,并为派生类提供低级服务。这是.NET框架中所有类的最终基类;它是类型层次结构的根。
语言通常不需要类来声明从Object继承,因为继承是隐式的。
因为.NET框架中的所有类都是从Object派生的,所以在Object类中定义的每个方法在系统中的所有对象中都可用。派生类可以而且确实会重写其中的一些方法。
因此,并不是C#中的每种类型都是从System.Object
派生的。即使对于这些类型,您仍然需要注意reference types和value types之间的区别,因为它们的处理方式非常不同。
拳击:
虽然值类型确实继承自System.Object
,但它们在内存中的处理方式与引用类型不同,并且它们在代码中如何通过方法传递的语义也不同。实际上,值类型不会被视为对象(引用类型),直到您通过将值类型包装为引用类型来显式指示应用程序这样做。参见more information about boxing in C# here。
发布于 2009-08-13 11:51:57
有点晚了,但我在SO上的一个搜索结果中发现了这一点,并认为下面的链接会对后代有所帮助:
Eric Lippert discusses this very thoroughly,用一个更好的(限定的)语句:
纠正这个错误的方法是简单地将“源自”替换为“可转换为”,并忽略指针类型: C#中的每个非指针类型都可以转换为object。
如果你讨厌从编写编程语言的人那里读到图文并茂的解释,它的要点是(抛开指针不谈),像Interface或泛型参数类型声明("T")这样的东西不是对象,但保证在运行时可以作为对象处理,因为它们有一个明确的实例,那将是一个对象。其他类型(类型、枚举、委托、类等)都是对象。包括值类型,它可以被装箱到object,正如其他答案所讨论的那样。
发布于 2009-01-12 18:05:47
这里的一些人对面向对象编程中的“对象”有一个奇怪的概念。为了使某个对象成为对象,它不必是引用类型,或者更一般地说,遵循任何正式的实现。
这意味着在面向对象的世界中,您可以作为一等公民对其进行操作。由于您可以对C#中的值执行此操作(感谢自动装箱),因此一切都确实是一个对象。在某种程度上,这甚至适用于函数(但可以说不适用于类)。
这在实践中是否相关是另一个问题,但这是我再次注意到的OOP的一个普遍问题。没有人清楚OOP的定义(是的,大多数人都认为它与多态性、继承和封装有关,有些人为了更好地衡量而加入了“抽象”)。
从使用的角度来看,C#中的每个值都像一个对象一样处理。也就是说,我喜欢目前被接受的答案。它提供了两个重要的技术方面。
请注意,在其他上下文中,例如C++,强调其他方面,因为C++不一定是面向对象的,而且更多地关注低级方面。因此,对象、POD和内置原语之间的区别有时是有意义的(但有时又不是)。
https://stackoverflow.com/questions/436211
复制相似问题