logo标签列表

惯例问题：何时使用Getter / Setter函数而不是使用属性？

c#
15

我认为在C#中，当试图操纵类中的字段时应该使用属性(Properties)。但是当涉及到复杂计算或数据库时，我们应该使用getter/setter。

这种做法正确吗？

什么时候使用getter而不是属性(Properties)呢？

1
这里有更多相关内容：https://dev59.com/73E85IYBdhLWcg3wLAQV - Steven Sudit
9个回答
20
.NET设计准则在属性 vs. 方法一节中提供了一些答案。基本上，属性与字段具有相同的语义。您不应该让属性抛出异常，属性不应该具有副作用，顺序不重要，并且属性应该快速返回。如果其中任何一件事可能发生，最好使用方法。指南还建议使用方法返回数组。在决定是使用属性还是方法时，将其视为字段会有所帮助。想想属性的行为并问自己：“如果这是类上的字段，如果它表现出与它相同的方式，我会感到惊讶吗？”例如，考虑TcpClient.GetStream方法。它可以根据连接是否建立而抛出多个异常，并且在尝试获取流之前配置TcpClient很重要。因此，它是一个Get方法而不是属性。如果仔细查看设计准则，您会发现通常并不是偏好的问题；在某些情况下，使用方法而不是属性有很好的理由。
太棒了！你说得比我好（还带有参考资料！）。我仍然认为考虑我们的同行开发人员也很重要，因为我们都可能不得不使用别人的糟糕代码。对未来维护人员的礼貌是如此罕见的品质，似乎！ - Sean Hanley
2
如果您的语言支持属性，只需使用属性即可。
2

使用属性。微软的框架设计指南书中有一个有趣的提示，如果你有一个属性并需要添加更复杂的set/get方法，那么你应该消除该属性，仅使用get/set方法。

1

这完全是个人偏好。编译后，无论哪种方式都会变成getter/setter函数。

我个人在设置和检索成员值时不带任何副作用地使用属性。如果检索/保存值有副作用，则使用函数。

1

我认为应该始终问自己哪个更有意义。方法通常被理解为要执行的操作，并且通常以此方式命名 - open()，flush()，parse()。属性通常被理解为更高级的字段/变量 - DisplayName，AutoSize，DataSource。

我注意到这在自定义控件开发中经常出现。由于它可能被许多其他人使用，而这些人并没有编写它，您可能不在身边询问，最好选择一个具有逻辑意义且不会使您的同事开发人员感到惊讶的设计。

1

当一个值是只写的或者有多个值需要一次性设置时，我倾向于使用setter。此外，像你一样，我的直觉也是使用getter和setter作为一个进程可能会长时间运行、生成线程或执行其他非平凡工作的信号。另外，如果一个setter在类中具有非明显的先决条件，我可能会使用getter或setter代替，因为人们很少阅读属性文档，并且期望属性随时可访问。但即使在这些情况下，如果属性可以使调用代码更易读，我仍然可能使用属性。

0

微软的回答很好，但我想再添加一些关于读写属性的规则（顺便说一下，微软有时也会违反这些规则，导致很多混乱）：(1) 属性设置器通常不应影响那些不被视为正在设置其属性的对象的可观察属性；(2) 将属性设置为一个值，然后再设置为另一个值，应该使任何受影响的对象处于与仅将其设置为第二个值相同的（可观察）状态；(3) 将属性设置为其getter返回的值不应产生任何可观察效果；(4) 通常，设置属性不应导致任何其他读写属性发生变化，尽管它可能会更改其他只读属性（请注意，大多数违反此规则的情况都会违反#2和/或#3，但即使在不违反这些规则的情况下，这样的设计仍然似乎是可疑的）。使对象在设计器中可用可能需要给它一些不遵循这些规则的属性，但不应该通过setter方法进行不遵循这种语义的运行时更改。

在许多情况下，拥有一个只读属性和一个单独的“Set”方法可能是合适的（例如，对于控件的“Parent”属性，这是我的首选）。在其他情况下，拥有几个相关的只读属性可能很有用，这些属性受一个读/写属性的影响（例如，可能有一个只读属性，指示控件及其所有父级是否可见，但此功能不应包含在读/写Visible属性中）。
0

忘记Getter和Setter方法吧，直接使用属性（Properties）。

有趣的是，属性最终会以Setter和/或Getter方法的形式出现在程序集中。只需一点元数据，Setter和/或Getter就可以成为属性。因此，实际上，属性=Setter/Getter方法。

0

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

并且它们不应该具有任何副作用。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接