如何在C#属性中改善新的Field关键字
C#属性是数据如何在类中访问和保护的核心部分。 它们介于私人数据成员和公共访问之间,允许开发人员控制值的读取和写入方式。 在他的视频"在10分钟或更短时间内了解 C# 14 中的新字段关键字如何改进属性"中,Tim Corey解释了C#14如何通过新字段关键字对属性进行有意义的改进。
在这篇文章中,我们将通过逐步查看Tim的视频,深入了解C#中的属性。Tim的解释是实用的,并以示例为驱动,展示了新关键字如何改进自动实施属性、简化验证,并减少样板代码——同时不改变开发人员已经依赖的相同语法。 这里的目标是通过遵循Tim的精确推理和演示来更好地理解C#属性。
Overview of C# Properties and the Upgrade in C# 14
Tim首先解释说C#14中的C#属性有一个重大升级。他明确指出,视频的重点是新字段关键字,它会影响如何在内部实现自动属性。 Tim还提到C#14与.NET 10和Visual Studio 2026一起发布,尽管这个功能本身可能在更早的.NET版本中也能运行。
他将该视频定位为简短、聚焦的解释,用于解答一个具体的问题:我们如何在真实代码中使用这个新功能? 这为实际操作演练设置了基调,而不是对属性定义的理论讨论。
Person类示例和自动属性
在0:23左右,Tim引入了一个带有简单公共类Person的控制台应用程序。 该Person类包含几个公共属性,包括:
public string FirstName
public string LastName
- public int Age
Tim解释说这些是自动实现的属性(也称为自动化实现的属性)。 因为编译器在幕后自动创建了一个辅助字段,所以没有可见的私有变量或私有字段。
他还包含了一个未自动实现的Demo属性。 相反,它使用一个私有字符串辅助字段(_demo)并通过一个只读属性使用get访问器将其公开。 此对比在视频的后期变得重要。
在Program.cs中使用属性
Tim接着转到类Program并显示了如何在public static void main(或者静态 void main string args,概念上)中创建Person对象。 他使用以下代码实例化一个新person:
new Person { FirstName = "Tim", LastName = "Corey" }Tim指出属性允许在类外访问,而仍然隐藏私有数据成员。 他检索了诸如姓、年龄和演示的值,展示了如何像访问字段一样访问属性,即使它们实际上在后台是特殊方法。
自动属性中无效值的问题
在大约1:23,Tim故意赋予了一个无效值:
person.LastName = null;即使LastName是必需的,并且未标记为可空,运行时仍然可以进行赋值。Tim解释说自动属性不能自动保护免受无效值的影响。 编译器会警告您,但set方法仍然接受该值。
这展示了自动实现属性的一个关键问题:虽然它们简洁,但没有内置方法来添加验证。 无效数据可以穿过并悄悄打破假设。
带有辅助字段的传统完全属性
大约在2:58,Tim展示了早期版本的C#中开发人员所做的事情。 他将LastName转换为一个完全实现的属性,具有:
一个私有字符串辅助字段
一个检查属性值的set访问器
- 一个抛出无效值的异常
Tim强调这种方法虽然给了对属性访问器的全控,但显得很冗长。 与自动属性的单行语法相比,属性现在需要好几行。
他还解释说,从自动属性切换到完全属性不会破坏现有代码,因为属性名、可访问性级别和外部使用方式保持不变。
新的field关键字作为中间立场
在4:19,Tim引入了C# 14中的关键改进。仍然使用自动属性结构,他只修改了set访问器,用field关键字。
Tim解释说field代表正常情况下保持隐藏的由编译器生成的私有字段。 通过分配field = value,开发人员现在可以截取并验证属性值,而无需声明他们自己的私有变量。
这保持了开发人员习惯的相同语法,同时增加了灵活性。 Tim指出,这减少了代码,同时仍允许验证逻辑,将其置于自动属性和完全属性之间。
作用域备份字段和属性隔离
Tim解释说,field关键字的作用域限于其出现的属性。 每个属性有自己的备份字段,不存在跨属性干扰的风险。
如果在另一个属性中使用相同的语法,比如FirstName,它指的是该属性自己的备份字段。 这使得该特性可预测且安全,可跨多个公共属性使用。
验证类似年龄的数字属性
在6:16左右,Tim将同样的方法应用于公共int Age属性。 他分配了一个无效的负值,并解释了为什么不应该允许此值。
Tim展示了一种不同的策略而不是抛出异常:忽略无效值。 set方法会在将值分配给field之前检查值是否在有效范围内。
这表明新方法同样适用于私有int age、数字验证和条件逻辑——而不需要将属性转换为完整实现。
使用field关键字的命名冲突
Tim接着讨论了一个潜在的边缘情况:命名冲突。 如果类中已经包含名为field的变量,它可能会与属性内的新关键字发生冲突。
他展示了这如何导致混淆和意外行为。 Tim解释了解决方案是显式引用变量使用this.field或@field。 这样可以将变量名与备份字段关键字区分开来。
Tim强烈建议重命名这样的变量作为良好的实践,尤其是在升级现有代码库时。
命名冲突不适用的地方
Tim澄清说,field关键字仅在属性访问器内部具有特别意义。 在构造函数、方法或类的其他部分,field表现得像普通变量。
这种区分帮助开发人员了解何时存在编译器生成的备份字段,何时不存在。
来自Tim Corey的最后思考
Tim在其视频结尾总结了新field关键字的工作原理及其为何改进了C#中的属性。 它使开发人员能够在仍使用自动属性的同时添加验证、控制和清晰度。
他鼓励观众尝试这一特性,探索其如何适合他们的编码风格,并仔细考虑命名惯例。 Tim在视频结尾强化了这一改变使得属性更具表现力而不增加不必要的复杂性。

