C# 在确定何时将类成员作为属性而不是方法实现时，哪些准则是合适的？

已开始显示在“赞助商”区域中的属性似乎表明属性仅适用于逻辑数据成员（请参阅文档第34-35页）。在下列情况下，方法被视为合适：

• 该操作是一种转换，例如Object.ToString（）。
• 操作很贵，你想和用户交流，他们应该考虑缓存结果。
• 使用get访问器获取属性值会产生明显的副作用。
• 连续两次调用成员会产生不同的结果。
• 执行顺序很重要。
• 该成员是静态的，但返回一个可以更改的值。
• 该成员返回一个数组。

---

大多数开发人员是否同意上述属性与方法的争论？若然，原因为何？如果没有，为什么不呢？

这些都是有趣的指南，我同意它们。有趣的是，他们是根据“除以下内容外，一切都是属性”来设置规则的。也就是说，它们是避免问题的很好的指导方针，将某些东西定义为以后可能导致问题的属性

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

完全同意

根据编码指南，属性是“名词”，方法是“动词”。请记住，用户可能会经常调用该属性，同时认为这是一个“便宜”的操作

---

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

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

人们有时似乎忘记（*）的一点是，调用方应该能够以任何顺序设置属性。对于支持设计器的类尤其重要，因为您无法确定生成的代码是否会设置属性

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

---

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

这些准则的有趣之处在于，它们显然是拥有扩展属性和扩展方法的论据。羞耻。

我个人从来没有得出结论，也没有直觉认为房地产速度很快，但指南说应该如此，所以我接受了

---

在避免FxCop警告的同时，我总是很难给我缓慢的“get”方法命名。GetPeopleList（）听起来不错，但FxCop告诉我它作为属性可能更好。

这是扩展属性的参数吗？@ScottDorman：本质上是因为在某些情况下，扩展成员在逻辑上更像是属性而不是方法。例如，如果经常需要

矩形的中心X坐标，可以定义扩展方法
CenterX（）
，但扩展属性
CenterX
似乎更自然。FxCop会产生大量误报。在这种情况下，排除冲突是正确的。Generate/Build/RetrievePeopleList？DateTime.Now可能是一个文本异常，但从逻辑上讲，每次调用都返回相同的内容。