常规问题：何时使用Getter/Setter函数而不是属性当我试图操作类中的字段时，我应该使用C#Propertiesin。但是当涉及到复杂的计算或数据库时，我们应该使用getters/setters。这是对的吗？什么时候使用s/getter属性？.NET设计指南的“属性和方法”部分对此问题提供了一些答案。基本上，属性与字段具有相同的语义。你不应该让属性抛出异常，属性不应该有副作用，顺序无关紧要，属性应该相对快速地返回。如果发生任何这些事情，最好使用一种方法。该指南还建议使用返回数组的方法。在决定是使用属性还是方法时，如果我将其视为字段会有所帮助。我考虑了这个属性的行为并问自己，“如果这是一个类中的字段，如果它以这种方式表现，我会感到惊讶吗？”例如，考虑TcpClient.GetStream方法。它可以根据连接是否建立而抛出几个异常，在尝试获取流之前配置TcpClient很重要。因此，它是Get方法而不是属性。如果仔细查看设计指南，您会发现这通常不是偏好问题；在某些情况下使用方法而不是属性是有充分理由的。如果您的语言支持属性，只需使用属性即可。使用属性。MS的FrameworkDesignGuidelines书中一个有趣的注释是，如果您有一个属性并且需要为更复杂的set/get添加额外的方法，那么您应该消除该属性并仅使用get/set方法。这都是个人喜好。当它被编译时，它是一个getter/setter函数。我个人在设置和检索成员值时使用属性，没有任何副作用。如果检索/保存值有副作用，那么我使用一个函数。我会说总是问问自己哪个更有意义。方法往往被理解为要执行的操作，通常措辞如下-open()、flush()、parse()。属性往往被理解为更高级的字段/变量-DisplayName、AutoSize、DataSource。我注意到自定义控件开发往往有很多问题。由于许多其他人可能会在不编写它的情况下使用它，而且您可能无法请求它，因此最好采用一种合乎逻辑且不会让您的开发人员感到惊讶的设计。当值是只写的，或者有多个值要同时设置时（很明显），我倾向于使用setter。此外，我的直觉和你一样，是使用getter和setter作为进程可能长时间运行、生成线程或执行其他一些重要工作的信号。此外，如果setter在类中具有不明显的先决条件，我可能会使用getter或setter，因为人们很少阅读有关属性的文档并期望属性始终可以访问。但即使在这些情况下，如果它可以使调用代码更易读，我也可以使用属性。忘记Getter和Setter方法吧。只需使用属性。有趣的是，属性最终出现在带有Setter和/或Getter方法的程序集中。Setter和/或Getter只是变成了带有一点元数据的属性。所以实际上，properties=setter/getter方法。属性应该是快速的，因为它们有一定的承诺。它们对于数据绑定也是强制性的。它们应该没有副作用。Microsoft的回答很好，但我要添加一些读写属性的规则（顺便说一下，Microsoft有时会违反这些规则，造成很多混乱）：(1)Propertysetter通常不应影响非对象可观察属性是被认为是其属性被设置的对象的一部分；(2)将一个属性设置为一个值，然后另一个应该使所有受影响的对象保持相同（可观察）状态，只需将其设置为第二个值；(3)将属性设置为其getter返回的值应该没有明显的效果；(4)一般而言，设置一个属性不应导致任何其他读写属性发生变化，但可能会改变其他只读属性（请注意，大多数违反此规则的行为都会违反#2和/或#3，但即使这些规则不会被违反，这些设计看起来仍然很可疑。让一个对象在设计器中可用可能需要给它一些不符合这些规则的属性，但是不遵循这些语义的运行时更改应该通过setter方法来完成。在在许多情况下，将只读属性与单独的“Set”方法一起使用可能是合适的（例如，对于控件的“Parent”属性，这是我的偏好）。在其他情况下，拥有多个受一个读/写属性影响的相关ReadOnly属性可能很有用（例如，拥有一个指示控件及其所有父级是否可见的只读属性可能很有用，但这样的功能不应该包含在读写Visible属性中）。以上就是C#学习教程：套路题：什么时候使用Getter/Setter函数而不是使用Property共享的全部内容。如果对大家有用，需要进一步了解C#学习教程，希望大家多加关注——本文来自网络收藏，不代表立场，如涉及侵权，请点击有权联系管理员删除。如需转载请注明出处：
