3 回答

TA貢獻1830條經驗 獲得超9個贊
這里的問題是,這實際上是兩個問題-一個問題是關于繼承的,在這種情況下答案是“幾乎所有東西”,另一個問題是關于引用類型vs值類型/內存/裝箱的,而答案是“否”。 ”。
遺產:
在C#中,以下是正確的:
所有值類型(包括枚舉和可為null的類型)均源自System.Object。
所有類,數組和委托類型都從派生System.Object。
接口類型不是從派生的System.Object。它們都可以轉換為System.Object,但是接口僅派生自其他接口類型,而System.Object不是接口類型。
沒有指針類型的派生System.Object,也不能直接轉換為System.Object。
“開放”類型參數類型也不是從派生的System.Object。類型參數類型不是從任何東西派生的。類型參數被約束為從有效的基類派生,但它們本身并非從任何東西“派生”。
從MSDN條目中的System.Object:
支持.NET Framework類層次結構中的所有類,并為派生類提供低層服務。這是.NET Framework中所有類的最終基類。它是類型層次結構的根。
語言通常不需要類聲明從Object的繼承,因為繼承是隱式的。
由于.NET Framework中的所有類均派生自Object,因此Object類中定義的每個方法在系統(tǒng)中的所有對象中均可用。派生類可以并且確實會覆蓋其中一些方法。
因此,并非C#中的每種類型都源自System.Object。即使對于那些類型,您仍然需要注意引用類型和值類型之間的區(qū)別,因為它們的處理方式非常不同。
拳擊:
雖然值類型確實從中繼承System.Object,但它們在引用中與引用類型在內存中的處理方式有所不同,并且它們如何通過代碼中的方法傳遞的語義也有所不同。實際上,除非您通過將其裝箱為引用類型來明確指示應用程序這樣做,否則值類型不會被視為對象(引用類型)。在此處查看有關C#中拳擊的更多信息。

TA貢獻1995條經驗 獲得超2個贊
聚會晚了一點,但我在SO的搜索結果中發(fā)現了這一點,并認為下面的鏈接對子孫后代有幫助:
埃里克·利珀特(Eric Lippert)對此進行了非常詳盡的討論,并提出了更好(合格)的陳述:
糾正這個神話的方法是簡單地將“源自”轉換為“可轉換為”,并忽略指針類型:C#中的每個非指針類型都可以轉換為對象。
要點是,如果您不喜歡閱讀寫編程語言的人的插圖說明,那就是(不包括指針),諸如Interface或通用參數類型聲明(“ T”)之類的對象都不是對象,但可以保證一定要在運行時可被視為對象,因為它們具有一個明確的實例,它將是一個對象。其他類型(類型,枚舉,委托,類等)都是對象。包括值類型,可以將其裝箱為對象,因為其他答案已經討論過。

TA貢獻1802條經驗 獲得超4個贊
這里有些人對面向對象編程中的“對象”有一個奇怪的概念。為了讓事情成為一個對象時,它并沒有必須是引用類型,或者更一般地說,按照任何正式實施。
這意味著您可以在面向對象的世界中以一流公民的身份對其進行操作。由于您可以對C#中的值執(zhí)行此操作(這要歸功于自動裝箱),因此所有內容實際上都是一個對象。從某種意義上說,對于函數(甚至可以說對于類而言),這甚至是正確的。
這在實踐中是否相關是另一個問題,但這是OOP的普遍問題,我再次注意到。關于OOP的定義,尚無一個明確的定義(是的,大多數人都認為OOP與多態(tài)性,繼承和封裝有關,有的則將“抽象”作為一種很好的衡量標準)。
從使用角度來看,C#中的每個值都像對象一樣處理。也就是說,我喜歡當前接受的答案。它提供了兩個重要的技術方面。
請注意,在其他上下文中,例如C ++,由于C ++不一定是面向對象的,因此會強調其他方面,此外,它會更多地關注于底層方面。因此,有時可以區(qū)分對象,POD和內置基元(有時又不是)。
- 3 回答
- 0 關注
- 527 瀏覽
添加回答
舉報