使用默认访问权限的自动实现属性而不是使用公共字段有什么好处?

时间:2011-12-29 21:20:51

标签: c# properties

  

可能重复:
  C#: Public Fields versus Automatic Properties
  Do I need to use { get; set; } with c# fields that have no special actions when getting and setting

考虑以下两个选项:

public int Foo { get; set; }

public int Foo;

它们似乎在语义上是等价的,我相信它们甚至会编译成同一个IL。那么使用该物业有什么好处?看到一个公共领域让我感到不安,但我想不出使用属性语法的任何具体优势。如果将来需要显式的getter和setter,public int Foo;可以替换为public int Foo { ... },而无需进行其他更改。我能想到的最好的是属性语法只是感觉更好,但我很难用这个理由来说服其他人。

在这种情况下使用属性语法有什么好处(如果有的话)?

4 个答案:

答案 0 :(得分:5)

主要优点是:

  1. 面向未来的API - 如果您以后需要getter或setter中的逻辑,那么您的公共API不会发生变化。
  2. 数据绑定 - 大多数数据绑定框架仅适用于Properties,而不是Fields。

答案 1 :(得分:0)

赞成

  • 轻松宣言

缺点

  • 无法在set / get
  • 中设置breakpoint
  • get / set
  • 中没有代码
  • 不要使用WPF DataBinding
  • 没有像default value这样的概念,因为它背后没有default field

优点缺点与项目实施严格相关。

只是一些提示,非常确定其他人会添加其他内容......

答案 2 :(得分:0)

我不相信它们会编译到同一个IL,因为属性的get和set实际上是IL级别的函数和处理反射时的函数。以下是一些理由:

  1. 反射<!/ LI>
  2. 序列化/反序列化仅适用于公共属性,而不适用于公共字段。
  3. 调试时,您可以在get或set上设置断点,这有助于跟踪访问变量的时间,特别是如果您看到一个傻瓜值并且您不知道它来自何处。< / LI>

答案 3 :(得分:0)

我们不使用自动实现的属性的主要原因是那些序列化成员而不是属性的序列化机制(例如.Net远程处理的二进制序列化)。

在这种情况下,如果您有两个应用程序分别编译同一个类并交换该类的序列化副本,则无法保证它将正确反序列化,因为您无法控制私有成员的名称。 / p>