什么时候使用方法而不是属性来定义类更好？

Question

与an earlier question of mine 部分相关，我有一个系统，我必须将复杂数据存储为字符串。我没有将这些字符串解析为各种单独的对象，而是创建了一个包含所有这些对象的类，它具有一些解析器逻辑，可以将所有属性编码为字符串，或解码字符串以获取这些对象。这一切都很好。这个问题不是关于解析器本身，而是关于我应该在哪里存放解析器的逻辑。将其作为属性还是作为方法是更好的选择吗？

对于属性，比如public string DataAsString，get 访问器将包含将所有数据编码为字符串的逻辑，而set 访问器将解码输入值并设置所有类实例中的数据。看起来很方便，因为输入/输出确实是一个字符串。

在方法的情况下，一个方法是Encode()，它返回编码字符串。然后，要么构造函数本身包含解码字符串的逻辑并需要字符串参数，要么我编写一个单独调用的Decode(string str) 方法。无论哪种情况，都将使用方法而不是属性。

那么，就代码的实际运行而言，这些路径之间是否存在功能差异？还是它们基本上是等效的，然后归结为个人喜好的选择，或者哪个看起来更好？在那种问题中……无论如何，哪个看起来更干净？

Answer 1

没有功能上的区别；从行为的角度来看，属性只是一对 get 和 set 方法。

然而，属性通常是轻量级的。如果您的属性的 getter 或 setter 正在执行大量计算，那么通常鼓励将它们移至方法中。

这有明显的例外（即 ORM 领域中的延迟加载，get 可能会触发数据库调用）。

Answer 2

“名词”：约定是属性不执行实际的业务逻辑，也没有副作用，即更改对象状态（设置值除外）。

“动词：方法应该起作用，但有副作用。

对我来说，“转换”、“解析”或“编码”之类的东西听起来像是动词。我会使用方法。

Answer 3

从技术上讲，他们可以做同样的事情。一般来说，如果涉及到复杂的处理，我会把它放在一个方法而不是一个属性中。这背后的主要原因（尽管我并不是说人们应该假设这一点），是人们普遍认为属性应该允许快速访问数据，其中方法调用期望它可能需要几个周期才能完全的。人们应该假设吗？绝对不是，但他们确实如此。

我喜欢使用方法来提醒与我的代码交互的人，“嘿，这是一个方法，正在进行一些处理，所以不要假设你会立即得到结果。”您也不能进行异步属性访问。您可以触发方法并在结果返回时收到通知。

Answer 4

如果您的类将用于数据绑定情况，那么您将需要属性。否则，我建议您参考其他答案。

Answer 5

就个人而言，我的属性非常愚蠢，只在极端情况下进行某些检查。即检查它返回的参数是否不为空，如果是，则更新它或抛出异常

我们以 Person 类为例 在这种情况下，Person.Name 作为属性是有意义的。 Person.Speak() 作为属性没有意义。

这完全取决于它所执行的功能。

Answer 6

还有一点没有提到，如果一个对象上的一个或多个读写属性被写入，然后在没有任何干预方法调用的情况下全部读回，读取的值应该与写入的值匹配。如果写入属性 Foo 会导致读写属性 Bar 的值发生变化，那么在我看来，这将是一个好兆头，一个或另一个应该是一对显式的 getter-setter 方法而不是一个属性。 .net 中有许多类违反了这一原则，但我认为这种行为是草率的。也许最严重的违规者是 Control 的 Visible 属性。写入属性会更新其状态无法读取的字段，而读取属性会返回一些计算的结果。更好的设计是拥有一个可读写的 Hidden 属性和一个只读的 Visible 字段。顺便说一句，在一个稍微类似的注释上，我会将 StringBuilder 的“长度”属性设为只读，但有截断或填充它的方法；我唯一拥有的读写属性就是 Value。