什么准则适用于确定何时将类成员实现为属性而不是方法

本文关键字：属性 实现 方法 成员 适用于 何时 什么 | 更新日期: 2023-09-27 17:47:24

SubMain的.NET编码标准PDF已开始显示在"赞助商"区域，这似乎表明属性仅适用于逻辑数据成员（请参阅文档的第34-35页）。在以下情况下，方法被认为是合适的：

  • 该操作是一个转换，例如Object.ToString（）。
  • 该操作非常昂贵，以至于您希望与用户通信，让他们考虑缓存结果。
  • 使用get访问器获取属性值会产生明显的副作用。
  • 连续调用成员两次会产生不同的结果。
  • 执行顺序很重要。
  • 该成员是静态的，但返回一个可以更改的值。
  • 成员返回一个数组。

大多数开发人员是否同意上面关于属性与方法的争论？如果是，为什么？如果没有，为什么不呢？

什么准则适用于确定何时将类成员实现为属性而不是方法

它们看起来很好，基本上符合MSDN成员设计指南：

http://msdn.microsoft.com/en-us/library/ms229059.aspx

人们有时似乎忘记了一点（*），即调用者应该能够按任何顺序设置属性。对于支持设计器的类来说尤其重要，因为您不能确定顺序生成的代码将设置属性。

（*）我记得Codeplex上Ajax控制工具包的早期版本有很多错误，因为开发人员忘记了这一个。

至于"连续调用成员两次会产生不同的结果"，每个规则都有一个例外，如属性DateTime.Now所示。

这些都是有趣的指导原则，我同意它们。有趣的是，他们制定的规则是基于"除以下内容外，所有内容都是属性"。也就是说，它们是通过将某些东西定义为以后可能引发问题的财产来避免问题的良好指南。

归根结底，属性只是一种结构化方法，因此我使用的经验法则是基于对象定向的——如果成员表示实体拥有的数据，则应将其定义为属性；如果它表示实体的行为，那么它应该作为一个方法来实现。

完全同意。

根据编码指南，属性是"名词"，方法是"动词"。请记住，用户可能会经常打电话给该物业，同时认为这是一个"廉价"的操作。

另一方面，通常预计一个方法可能"需要更多的时间"，因此用户会考虑缓存方法结果。

这些准则的有趣之处在于，它们显然是具有扩展属性和扩展方法的一个参数。羞耻

我个人从未得出结论，也没有直觉认为属性很快，但指南说它们应该很快，所以我接受了。

在避免FxCop警告的同时，我总是纠结于如何命名我的慢速"get"方法。GetPeopleList（）对我来说很好，但后来FxCop告诉我，它作为一个属性可能会更好。

相关文章：