新關鍵字字段如何改善 C# 屬性

Tim Corey

10m 40s

C# 屬性是資料在一個類裡如何被存取及保護的核心部分。 它們位於私有資料成員和公共存取之間，使開發者能控制值的讀取和寫入方式。 在他的影片"How The New Field Keyword Improves Properties in C# 14 in 10 Minutes or Less"中，Tim Corey 解釋了 C# 14 如何通過新的 field 關鍵字對屬性引入重大改進。

在本文中，我們將通過逐步觀看 Tim 的影片，深入了解 C# 屬性。Tim 的解釋是實用且以範例驅動的，展示了新關鍵字如何改善自動實現屬性、簡化驗證以及減少樣板，而不改變開發者已依賴的相同語法。 這裡的目標是通過遵循 Tim 的準確推理和示範來更好地理解 C# 屬性。

Overview of C# Properties and the Upgrade in C# 14

Tim 首先解釋了 C# 14 中對 C# 屬性的一次重大升級。他明確指出影片的重點是新引入的 field 關鍵字，它影響著自動屬性在內部的工作方式。 Tim 也提到 C# 14 是隨著 .NET 10 和 Visual Studio 2026 一起推出的，儘管該功能本身可能在較早的 .NET 版本中運行。

他將影片定調為一個快速、專注的解釋，旨在解答一個具體問題：我們如何在實際程式碼中使用這個新特性？ 這使影片更像是一個實際操作的導覽，而非屬性定義的理論討論。

Person 類別範例和自動屬性

在大約 0:23 時，Tim 介紹了一個具有簡單 public 類別 Person 的控制台應用程式。 這個 Person 類包括幾個公共屬性，其中包括：

• public string FirstName

• public string LastName

• public int Age

Tim 解釋這些是自動實現屬性（也稱為自動實現的屬性）。 沒有可見的私有變數或私有欄位，因為編譯器自動在背景中建立了一個支持欄位。

他還包括一個不是自動實現的 Demo 屬性。 相反，它使用了一個私有字串支持欄位（_demo），並僅通過 get 存取子曝光為只讀屬性。 這種對比在後續影片中變得重要。

在 Program.cs 中使用屬性

然後，Tim 進入程式類，展示如何在 public static void main（或 static void main string args，概念上）中建立 Person 物件。 他使用以下方式實例化一個新人物：

new Person { FirstName = "Tim", LastName = "Corey" }

new Person { FirstName = "Tim", LastName = "Corey" }

Tim 指出屬性允許在類別外部存取，卻仍然隱藏私有資料成員。 他獲取了如姓氏、年齡和演示等值，展示了屬性如何像欄位一樣被存取，即使它們實際上是在底層是特殊的方法。

自動屬性中無效值的問題

在大約 1:23 時，Tim 故意賦予一個無效的值：

person.LastName = null;

person.LastName = null;

即使 LastName 是必需的且未標記為可空的，該賦值在運行時仍然有效。Tim 解釋說，自動屬性並不能自動防止無效值。 編譯器會提醒您，但 set 方法仍然接受該值。

這演示了自動實現屬性的關鍵問題：儘管它們簡潔，但它們不提供內建的方法來增加驗證。 無效的資料可以通過並靜默地破壞假設。

具有支持欄位的傳統完整屬性

約在 2:58 時，Tim 展示了開發者在早期 C# 版本中常用的方法。 他將 LastName 轉換為一個完全實現的屬性，包含：

• 私有字串支持欄位

• 檢查屬性值的 set 存取子

• 對無效值拋出異常

這種方法讓具體存取子得到完全控制，但 Tim 強調這樣變得冗長。 相比於自動屬性的單行語法，該屬性現在需要多行。

他也解釋從自動屬性切換到完整屬性不會破壞現有程式碼，因為屬性名稱、可存取性層級和外部使用保持不變。

新的 field 關鍵字作為一個中間立場

在 4:19 時，Tim 介紹了 C# 14 的關鍵改進。與其撰寫完整屬性，他保留自動屬性結構並僅使用 field 關鍵字修改 set 存取子。

Tim 解釋 field 代表了編譯器生成的通常保持隱藏的私有欄位。 通過將 field = value 賦值，開發者現在可以攔截和驗證屬性值而不需聲明自己的私有變數。

這保持了開發者習慣的相同語法，同時增加了彈性。 Tim 指出這樣既減少程式碼，還允許驗證邏輯，介於自動屬性和完整屬性之間。

作用域支持欄位和屬性隔離

Tim 解釋 field 關鍵字是在其出現的屬性內具有作用域的。 每個屬性都有自己的支持欄位，並且沒有跨屬性的干擾風險。

如果在另一個屬性（如 FirstName）中使用相同的語法，它指的是該屬性的自己的支持欄位。 這使得功能在多個公共屬性中具有可預測性和安全性。

像 Age 這樣的數字屬性驗證

在大約 6:16 時，Tim 將相同的方法應用於 public int Age 屬性。 他賦予一個無效的負值並解釋為何它不應被允許。

Tim 展示了一個不同的策略：忽略無效值，而不是拋出異常。 set 方法檢查值是否在有效範圍內再將其賦予欄位。

這演示了新方法同樣適用於私有 int age、數字驗證和條件邏輯——所有這些都不需要將屬性轉換為完整實現。

與 field 關鍵字的命名衝突

Tim 接著討論了一個潛在的邊緣情況：命名衝突。 如果類已包含名為 field 的變數，它會與屬性內的新關鍵字衝突。

他展示了這如何導致混淆和意外行為。 Tim 解釋解決方案是用 this.field 或 @field 顯式引用變數。 這區分了變數名稱和支持欄位關鍵字。

Tim 強烈建議改名這些變數作為良好實踐，特別是在升級現有程式碼庫時。

命名衝突不適用的情況

Tim 闡明 field 關鍵字只有在屬性存取器內才具特別意義。 在構造器、方法或類的其他部分中，field 表現得像普通變數。

這種區分幫助開發者理解編譯器生成的支持欄位何時存在以及何時不存在。

Tim Corey 的最終思考

Tim 以總結新 field 關鍵字的運作方式及其為何改進 C# 屬性結束影片。 它允許開發者在使用自動屬性的同時新增驗證、控制和清晰性。

他鼓勵觀眾嘗試此功能，探索它如何適應他們的編碼風格，並仔細考慮命名約定。 Tim 在影片結尾重申此更改使屬性更具表達性而不增加不必要的複雜性。