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