什么时候使用方法与属性进行类定义更好？

Question

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

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

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

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

Answer 1

没有功能差异;从行为的角度来看，属性只是get和set方法的对。

然而，属性通常是轻量级的。如果您的财产的吸气剂或制定者正在进行大量计算，那么通常会鼓励他们将其移至某种方法。

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

Answer 2

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

“动词：预计方法会起作用并产生副作用。

“转换”或“解析”或“编码”之类的声音对我来说就像动词一样。我会用方法。

Answer 3

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

我喜欢使用方法来注意与我的代码接口的人，“嘿，这是一种方法，有一些处理正在进行，所以不要以为你会立即获得结果。”您也不能拥有异步属性访问权限。您可以触发方法并在结果返回时收到通知。

Answer 4

如果您的类将用于数据绑定情况，那么您将需要属性。否则，我会将您推荐给其他答案。

Answer 5

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

我们以一个Person类为例 在这种情况下，Person.Name作为属性是有意义的。 Person.Speak（）作为一种财产没有意义。

这一切都取决于它正在执行的功能。

Answer 6

未提及的另一点是，如果写入对象上的一个或多个读写属性，然后在没有任何插入方法调用的情况下读回所有读写属性，则读取的值应与写入的值匹配。如果写入属性Foo会导致读写属性Bar的值发生变化，那么在我看来，这将是一个好的迹象，即一个或另一个应该是一对显式的getter-setter方法而不是属性。 .net中有许多类违反了这个原则，但我认为这种行为是草率的。也许最糟糕的罪犯是控制的可见属性。编写属性会更新其状态无法读取的字段，而读取属性会返回某些计算的结果。更好的设计是拥有读写隐藏属性和只读可见字段。顺便说一句，在一个稍微类似的说明中，我会将StringBuilder的“Length”属性设为只读，但是有截断或填充它的方法;我本来唯一的读写属性就是Value。