何时使用方法而不是属性来定义类？

Question

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

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

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

那么，在实际运行代码方面，这些路径之间是否存在功能差异？还是它们基本上是等效的，然后归结为个人偏好或哪个看起来更好的选择？在这种问题中...哪个方式看起来更清洁？

- Grace Note

Answer 1

在行为层面上，属性和一对get和set方法没有实质性区别。

然而，属性通常被设计成轻量级的。如果属性的getter或setter执行了大量的计算，则通常鼓励将它们移动到一个方法中。

当然也有明显的例外情况（例如，在ORM领域中进行惰性加载，其中get可能会触发数据库调用）。

- Adam Robinson

Answer 2

"名词": 按照惯例，属性不执行实际的业务逻辑，也没有副作用，即不会改变对象状态（除了设置一个值）。

"动词": 方法被期望执行工作并具有副作用。例如，“转换”、“解析”或“编码”听起来像是动词。我会使用方法。

- Jennifer Zouak

Answer 3

技术上讲，它们可以做同样的事情。通常，如果涉及复杂的处理，我会将其放在方法中而不是属性中。这样做的主要原因（虽然我并不是说人们应该假设这一点），是有一个普遍的看法认为属性应该允许快速访问数据，而方法调用则预期可能需要几个周期才能完成。人们应该假设这个吗？绝对不，但他们确实这么做了。

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

- kemiller2002

Answer 4

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

- Ray

Answer 5

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

以Person类为例 Person.Name作为属性是有意义的。 Person.Speak()作为属性是没有意义的。

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

- Pieter Germishuys

Answer 6

另外一个没有提到的问题是，如果在对象上写入了一个或多个读写属性，然后在没有任何中间方法调用的情况下读取所有属性，则读取的值应该与写入的值匹配。如果写入属性Foo会导致读写属性Bar的值发生变化，那么在我看来，其中一个属性应该是一对显式的getter-setter方法，而不是一个属性。.net中有许多违反这个原则的类，但我认为这种行为很草率。也许最糟糕的罪犯是Control的Visible属性。写入属性会更新一个无法读取状态的字段，而读取属性会返回一些计算结果。更好的设计应该是有一个可读写的Hidden属性和一个只读的Visible字段。顺便说一句，在一个稍微相似的注意事项上，我会将StringBuilder的“Length”属性设置为只读，但是有截断或填充它的方法；我唯一需要的读写属性是Value。

- supercat