【发布时间】：2010-09-09 04:27:09
【问题描述】：
让我印象深刻的是，在尝试操作类中的字段时应该使用 C# 中的属性。但是当涉及到复杂的计算或数据库时，我们应该使用 getter/setter。
这对吗？
你什么时候在属性上使用 s/getter？
【问题讨论】：
标签： c#
【发布时间】：2010-09-09 04:27:09
【问题描述】：
如果您的语言支持属性，请使用属性。
【讨论】：
这都是个人喜好。当它被编译时，结果证明它是 getter/setter 函数。
我个人在设置和检索成员值时使用属性，没有任何副作用。如果检索/保存值有副作用，那么我使用一个函数。
【讨论】：
使用属性。 MS 的框架设计指南书中的一个有趣的注释是，如果您有一个属性并且需要为更复杂的 set/get 添加额外的方法，那么您应该消除该属性并只使用 get/set 方法。
【讨论】：
我想说总是问自己哪个更有意义。方法往往被理解为要执行的动作，并且通常这样写——open()、flush()、parse()。属性往往被理解为更高级的字段/变量——DisplayName、AutoSize、DataSource。
这往往会在我注意到的自定义控件开发中出现。由于它有可能被许多其他没有编写它的人使用，并且您可能不会问，因此最好采用合乎逻辑且不会让您的开发人员感到惊讶的设计。
【讨论】：
当一个值是只写的或一次设置多个值时（显然），我倾向于使用 setter。我的直觉和你一样，是使用 getter 和 setter 作为进程可能长时间运行、产生线程或执行其他一些重要工作的信号。此外，如果 setter 在类中具有不明显的先决条件，我可能会使用 getter 或 setter，因为人们很少阅读有关属性的文档，并且属性应该始终可以访问。但即使在这些情况下，我也可能会使用一个属性，如果它有可能使调用代码更好读的话。
【讨论】：
忘记 Getter 和 Setter 方法。只需使用属性。
值得一提的是，Properties 最终在程序集中作为 Setter 和/或 Getter 方法结束。只需一点元数据，Setter 和/或 Getter 就变成了一个属性。所以实际上，properties = setter/getter 方法。
【讨论】：
.NET 设计指南在Properties vs. Methods 部分提供了这个问题的一些答案。
基本上，属性与字段具有相同的语义。你不应该让属性抛出异常，属性不应该有副作用，顺序不重要，并且属性应该相对快速地返回。如果这些事情都可能发生，最好使用一种方法。该指南还建议使用返回数组的方法。
在决定是否使用属性或方法时，如果我将其视为一个字段会有所帮助。我考虑了属性的行为并问自己，“如果这是类中的一个字段，如果它的行为方式如此，我会感到惊讶吗？”例如，考虑TcpClient.GetStream method。它可以根据是否建立连接抛出几个异常，并且在尝试获取流之前配置 TcpClient 非常重要。因此，它是一个 Get 方法而不是一个属性。
如果您仔细阅读设计指南，您会发现它通常不是偏好问题；在某些情况下使用方法而不是属性是有充分理由的。
【讨论】：
-
宾果游戏！你说得比我好（也有参考！）。我仍然认为考虑我们的其他开发人员也很重要，因为在某些时候，我们都可能不得不使用其他人的糟糕代码。对未来的维修人员礼貌是一种难得的品质，看来！
属性应该很快，因为它们有一定的承诺。它们对于数据绑定也是必需的。
而且它们应该没有副作用。
【讨论】：
微软的回答很好，但我会为读写属性添加更多规则（微软有时会违反这些规则，顺便说一句，会造成很多混乱）：(1) 属性设置器通常不应影响对象的可观察属性不被认为是正在设置其属性的对象的一部分； (2) 将一个属性设置为一个值，然后另一个值应该使任何受影响的对象处于相同的（可观察的）状态，就像简单地将其设置为第二个值一样； (3) 将属性设置为其 getter 返回的值应该没有可观察到的效果； (4) 通常，设置一个属性不应导致任何其他读写属性发生变化，尽管它可能会更改其他只读属性（请注意，大多数违反此规则的行为都会违反 #2 和/或 #3，但即使当这些规则不会被违反，这样的设计似乎仍然值得怀疑）。让一个对象在设计器中可用可能需要给它一些不遵循这些规则的属性，但是不遵循这些语义的运行时更改应该由 setter 方法完成。
在许多情况下，拥有一个只读属性和一个单独的“Set”方法可能是合适的（这是我的偏好，例如，对于控件的“Parent”属性）。在其他情况下，拥有几个受一个读/写属性影响的相关 ReadOnly 属性可能很有用（例如，拥有一个指示控件及其所有父项是否可见的只读属性可能很有用，但是这样的功能不应包含在读写 Visible 属性中）。
【讨论】：