属性和方法之间的界限应该在哪里？

Question

  

可能重复：
  Properties vs Methods

在很多情况下，很明显某些东西应该是属性还是方法，但是有些东西可能被认为是含糊不清的。

明显的属性：

• “name”
• “长度”

明显的方法：

• “的SendMessage”
• “打印”

暧昧：

• “有效”/“IsValid”/“验证”
• “InBounds”/“IsInBounds”/“CheckBounds”
• “AverageChildValue”/“CalcAverageChildValue”
• “ColorSaturation”/“SetColorSaturation”

我想我会倾向于模棱两可的方法，但有没有人知道有助于决定这一点的规则或惯例？例如。应该所有属性都是O（1）？属性是否应该无法更改其他数据（ColorSaturation可能会更改R，G，B值）？如果有计算或汇总，它不应该是财产吗？

从学术角度来看，（并不是因为我认为这是一个好主意）是否有理由不对属性发疯，只是在不参与争论的情况下制作所有类别的审讯，以及所有可以用一个参数改变关于类的一个并且不能失败，一个属性？

Answer 1

如果属性具有以下行为之一，我通常会将属性转换为函数

• 产生副作用（设置背景栏除外）
• 与现场访问
相比，实施成本高昂
• 实施的复杂性高于Log（N）
• 可以抛出异常

Answer 2

我发现了一些有关此内容的有趣文字

MSDN | Properties vs Methods

修改

它说的是：

时使用属性

• 该成员是逻辑数据成员

在

时使用方法

• 该操作是转换，例如Object.ToString。
• 操作非常昂贵，您希望与用户沟通，他们应该考虑缓存结果。
• 使用get访问器获取属性值会产生可观察到的副作用。
• 连续两次致电会员会产生不同的结果。
• 执行顺序很重要。请注意，应该能够以任何顺序设置和检索类型的属性。
• 该成员是静态的，但返回一个可以更改的值。
• 该成员返回一个数组。返回数组的属性可能会产生误导。
• 通常需要返回内部数组的副本，以便用户无法更改内部状态。这与用户可以轻易地认为它是索引属性的事实相结合，导致代码效率低下。

Answer 3

另一个考虑因素是可绑定性。大多数框架只能绑定到属性。例如，如果您希望IsValid可用于绑定（例如，作为OK按钮的IsEnabled属性的绑定源），那么它必须是属性而不是方法。

Answer 4

在决定是否使用属性或方法时，您还应该考虑该方法所涉及的工作量。即如果检索价值相对便宜，则将其作为财产，如果成本高昂，则将其作为一种方法。

Answer 5

如果您可以根据已有的东西计算某些东西，请使用方法，如果您的值必须是操作或计算其他属性的基础。

例如，如果您想检查某些用户输入是否是最新的，并且您可以使用您的独特专利算法来执行此操作，请使用方法Validate()。如果用户只是向您发送提交nis当前地址有效的表单，请使用属性valid。但这只是一种常见的方法，可能会根据您的实际需要而有所不同。

Answer 6

我个人会选择复杂性以及方法/属性将要做什么。如果我正在做的是设置一个值，即_name = something;，那么我选择了一个属性。即使我要做一些非常基本的计算或条件陈述，我也会坚持使用属性。但如果某些东西需要一些认真的工作甚至是适度的工作，我会使用一种方法。没有什么能比设置一个属性更让我感到害怕，而且突然发现了比我想象的更多的代码。