14

让我感到震惊的是，在尝试操作类中的字段时应该使用 C# 中的属性。但是当涉及到复杂的计算或数据库时，我们应该使用 getter/setter。

它是否正确？

你什么时候在属性上使用 s/getter？

4

9 回答 9

19

.NET 设计指南在“属性与方法”部分中提供了该问题的一些答案。

基本上，属性与字段具有相同的语义。你不应该让属性抛出异常，属性不应该有副作用，顺序不重要，并且属性应该相对快速地返回。如果这些事情都可能发生，最好使用一种方法。该指南还建议使用返回数组的方法。

在决定是否使用属性或方法时，如果我将其视为一个字段会有所帮助。我考虑了属性的行为并问自己，“如果这是类中的一个字段，如果它的行为方式如此，我会感到惊讶吗？” 例如，考虑TcpClient.GetStream 方法。它可以根据是否建立连接抛出几个异常，并且在尝试获取流之前配置 TcpClient 非常重要。因此，它是一个 Get 方法而不是一个属性。

如果您仔细查看设计指南，您会发现这通常不是偏好问题。在某些情况下使用方法而不是属性是有充分理由的。

于 2008-09-15T21:34:26.330 回答
2

如果您的语言支持属性，只需使用属性。

于 2008-09-15T21:19:54.103 回答
2

使用属性。MS 的框架设计指南书中的一个有趣的注释是，如果您有一个属性并且需要为更复杂的 set/get 添加额外的方法，那么您应该消除该属性并只使用 get/set 方法。

于 2008-09-15T21:22:56.013 回答
1

这都是个人喜好。当它被编译时，无论哪种方式，它都是 getter/setter 函数。

我个人在设置和检索成员值时使用属性而没有任何副作用。如果检索/保存值有副作用，那么我使用一个函数。

于 2008-09-15T21:20:57.110 回答
1

我想说总是问自己哪个更有意义。方法往往被理解为要执行的动作，通常用这样的措辞来表达—— open()、、、。属性往往被理解为更高级的字段/变量—— , , .flush()parse()DisplayNameAutoSizeDataSource

在我注意到的自定义控件开发中，这往往会出现很多问题。由于它有可能被许多其他没有编写它的人使用，而且您可能不会问，因此最好采用合乎逻辑且不会让您的开发人员感到惊讶的设计。

于 2008-09-15T21:30:04.203 回答
1

当一个值是只写的或一次设置多个值（显然）时，我倾向于使用设置器。我的直觉和你一样，是使用 getter 和 setter 作为进程可能长时间运行、产生线程或执行其他一些重要工作的信号。此外，如果 setter 在类中具有不明显的先决条件，我可能会使用 getter 或 setter，因为人们很少阅读有关属性的文档，并且属性应该始终可以访问。但即使在这些情况下，如果它可能使调用代码更好地阅读，我也可能会使用一个属性。

于 2008-09-15T21:33:16.597 回答
0

忘记 Getter 和 Setter 方法。只需使用属性。

值得一提的是，Properties 最终在程序集中作为 Setter 和/或 Getter 方法结束。只需一点元数据，Setter 和/或 Getter 就变成了一个属性。所以实际上，properties = setter/getter 方法。

于 2008-09-15T21:33:19.437 回答
0

属性应该很快，因为它们有一定的承诺。它们对于数据绑定也是必需的。

而且它们应该没有副作用。

于 2008-09-15T21:41:32.927 回答
0

微软的回答很好，但我会为读写属性添加更多规则（微软有时会违反这些规则，顺便说一句，造成很多混乱）：（1）属性设置器通常不应该影响对象的可观察属性，而不是被认为是正在设置其属性的对象的一部分；(2) 将一个属性设置为一个值，然后另一个值应该使任何受影响的对象处于相同的（可观察的）状态，就像简单地将其设置为第二个值一样；(3) 将属性设置为其 getter 返回的值应该没有可观察到的效果；(4) 通常，设置一个属性不应导致任何其他读写属性发生变化，尽管它可能会更改其他只读属性（请注意，大多数违反此规则的行为都会违反 #2 和/或 #3，但即使这些规则不会被违反，这样的设计仍然显得可疑）。使对象在设计器中可用可能需要为其提供一些不遵循这些规则的属性，但是不遵循这些语义的运行时更改应该由 setter 方法完成。

In many cases, it may be appropriate to have a read-only property and a separate "Set" method (that would be my preference, for example, for a control's "Parent" property). In other cases, it may be useful to have several related ReadOnly properties that are affected by one read/write property (e.g. it may be useful to have a read-only property that indicates whether a control and all its parents are visible, but such functionality should not be included in a read-write Visible property).

于 2010-11-23T16:07:56.667 回答