12

可能的重复：
属性与方法

在许多情况下，某些东西应该是属性还是方法是显而易见的，但是有些项目可能被认为是模棱两可的。

明显的属性：

  • “姓名”
  • “长度”

明显的方法：

  • “发信息”
  • “打印”

模糊的：

  • “有效”/“IsValid”/“验证”
  • “InBounds”/“IsInBounds”/“CheckBounds”
  • “AverageChildValue”/“CalcAverageChildValue”
  • “颜色饱和度”/“设置颜色饱和度”

我想我会倾向于使用模棱两可的方法，但是有人知道有助于决定这一点的规则或约定吗？例如，所有属性都应该是 O(1) 吗？属性是否应该不能更改其他数据（ColorSaturation 可能会更改 R、G、B 值）？如果有计算或聚合，它不应该是一个属性吗？

只是从学术的角度来看，（而不是因为我认为这是一个好主意）是否有理由不对属性发疯，而只是在不争论的情况下对课堂进行审讯，以及所有可以改变的事情具有单个参数且不能失败的类，一个属性？

4

6 回答 6

10

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

  • 导致副作用（除了设置支持字段）
  • 与说字段访问相比，实施成本很高
  • 实现的复杂度高于 Log(N)
  • 可以抛出异常
于 2010-03-12T23:01:37.510 回答
5

我发现了一些关于这个的有趣的文字

MSDN | 属性与方法

编辑

它说的是：

使用属性时

  • 该成员是逻辑数据成员

使用方法时

  • 该操作是一种转换，例如 Object.ToString。
  • 该操作非常昂贵，以至于您希望与用户交流他们应该考虑缓存结果。
  • 使用 get 访问器获取属性值会产生可观察到的副作用。
  • 连续调用该成员两次会产生不同的结果。
  • 执行顺序很重要。请注意，类型的属性应该能够以任何顺序设置和检索。
  • 该成员是静态的，但返回一个可以更改的值。
  • 该成员返回一个数组。返回数组的属性可能非常具有误导性。
  • 通常需要返回内部数组的副本，以便用户无法更改内部状态。再加上用户可以很容易地假设它是索引属性这一事实，导致代码效率低下。
于 2010-03-12T23:02:26.450 回答
4

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

于 2010-03-12T23:07:03.877 回答
1

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

于 2010-03-12T23:01:26.333 回答
0

如果您可以根据已有的东西计算某些东西，请使用方法，如果您的价值必须作为操作或计算其他东西的基础，那么它应该是财产。

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

于 2010-03-12T23:09:08.827 回答
0

我个人会根据复杂性以及方法/属性将要做什么来做出选择。如果我所做的只是设置一个值，即_name = something;，那么我将使用一个属性。即使我要做一些非常基本的计算或条件语句，我也会坚持使用属性。但是，如果某些事情需要一些严肃的工作，甚至是适度的工作，我会使用一种方法。没有什么比设置一个属性更让我恼火的了，突然间执行的代码比我预期的要多。

于 2010-03-12T23:38:10.523 回答