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

Question

可能重复:
属性与方法

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

明显属性:

• "名称"
• "长度"

明显的方法:

• "发信息"
• "打印"

暧昧:

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

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

仅仅从学术的角度来看,(而不是因为我认为这是一个好主意)是否有理由不对属性发疯,只是在不参与争论的情况下制作所有类别的审讯,以及可以改变的一切具有单个参数且无法失败的类,属性？

Answer 1

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

• 导致副作用(除了设置支持字段)
• 与现场访问相比,实施起来很昂贵
• 实现具有比Log(N)更高的复杂性
• 可以抛出异常

Answer 2

我发现了一些有趣的文字

MSDN | 属性与方法

编辑

它说的是:

使用属性时

• 该成员是逻辑数据成员

使用方法时

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