属性与功能(特别是.NET)

Question

我已经阅读了关于这个主题的一些讨论,而且我有些不明白.

最常见的答案似乎是:使用ReadOnly属性返回缓存数据,使用Function返回非缓存数据.根本不要使用WriteOnly属性,因为"它没有意义".

没有性能原因.在IL中,MyProperty get_MyProperty以及set_MyProperty方法存在.唯一的原因显然是应该假设上述答案.

那么,为什么还要使用ReadOnly Properties呢？为什么不将变量设为Public而不是Private？然后为什么要打扰属性呢？缓存数据 - >公共变量,非缓存数据 - >函数,写入数据 - > Sub

让我们忘记以上所有,并使用属性作为一个方便的功能？获取和设置数据的一个"项目".使用常识来了解Get是否不会返回缓存数据(可能导致延迟).

-Edit-我看到人们或多或少同意物业是最好的选择.我只是不明白为什么我发现了很多关于人们提倡反对财产的讨论.

Answer 1

只读属性的一个很好的理由是计算的值.在这种情况下,没有要导出的变量.

例如

public class Person {
  private readonly DateTime _birthday;
  public int Age { get { return (DateTime.Now - _birthday).TotalYears; } }
  ...
}

在这种情况下,是否将_birthday作为属性或字段公开肯定是有争议的.但对于像Age这样的其他计算值,将它们作为变量公开的唯一方法是将它们存储在对象中.在这种情况下,为Age提供额外的变量实质上是存储冗余信息.将其公开为计算属性具有较小的开销并避免存储冗余数据

Answer 2

原因#1 =属性可用于数据绑定.方法不能.

原因#2 =调试监视窗口时会自动显示属性/展开对象.方法不会以这种方式自动观看.

我记得在某个地方读过read属性不应该改变对象状态.我认为这是一个很好的做法,特别是考虑到#2的原因.只要您观察对象并在手表中展开它,就可以更改对象状态,从而使调试更加困难.

此外,如果昂贵的财产受到意外的约束,它可能会引入严重的性能问题.(属性可以从数据绑定中"隐藏"属性,但只是使它们成为方法意味着您不必担心它.)

属性是窗口开发的便利.它们在设计师等中被"使用"不同.

(我有时只是暴露一些变量.但我把它们命名为我的财产.所以而不是

整数mCounter = 0;

我只是做

整数计数器= 0;.

如果我将来某个时候必须做"额外的东西",我会创建具有相同名称的Property,并将变量重命名为mCounter.不可否认,这是我的懒惰,我并不真的推荐它.把它包装在一个房产里.)

Answer 3

属性可以方便地替代基于方法的操作。property-getter-setter 和执行相同操作的方法之间没有功能差异；事实上，如果您查看 IL，您会看到属性访问器被“get”和/或“set”方法替换。

使用属性而不是只允许访问变量的最强有力的原因是封装。假设您正在编写一个库并公开一个IsBlue变量。您分发库，每个人都喜欢并使用它。现在，是版本 2 的时候了，您想在用户设置时做一些事情IsBlue- 可能执行检查，可能缓存某些内容。为此，您必须将变量转换为属性或方法，并在那里进行检查。现在，您已经破坏了所有客户端代码 - 他们访问的变量不再存在。如果您最初将它实现为一个属性，您可以只修改该属性的代码，并保留二进制兼容性。