惯例问题：何时使用Getter / Setter函数而不是使用Property
当我试图操纵类中的字段时，应该使用C＃中的Properties。 但是当涉及复杂的计算或数据库时，我们应该使用getter / setter。
它是否正确？
你什么时候使用s / getter属性？
.NET设计指南在“ 属性与方法”部分中提供了对此问题的一些答案。
基本上，属性与字段具有相同的语义。 你不应该让一个属性抛出exception，属性不应该有副作用，顺序无关紧要，属性应该相对快速地返回。 如果发生任何这些事情，最好使用一种方法。 该指南还建议使用返回数组的方法。
在决定是否使用属性或方法时，如果我将其视为字段，则会有所帮助。 我想到了这个属性的行为，并问自己，“如果这是一个课堂上的一个领域，如果它的表现如此，我会感到惊讶吗？” 例如，考虑TcpClient.GetStream方法 。 它可以根据是否建立连接抛出几个exception，并且在尝试获取流之前配置TcpClient很重要。 因此，它是一个Get方法而不是属性。
如果你仔细看看设计指南，你会发现它通常不是偏好的问题; 在某些情况下使用方法而不是属性是有充分理由的。
如果您的语言支持属性，只需使用属性。
使用属性。 MS的框架设计指南书中有一个有趣的注意事项是，如果你有一个属性并且需要为更复杂的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方法。
属性应该很快，因为它们有一定的承诺。 它们对数据绑定也是强制性的。
它们应该没有副作用 。
微软的答案是好的，但我会为读写属性添加一些规则（微软有时会违反这些规则，顺便说一下，造成很多混淆）:( 1）属性设置器通常不应该影响非对象的可观察属性被认为是其财产被设定的对象的一部分; （2）将属性设置为一个值然后另一个值应将任何受影响的对象保持在相同（可观察）状态，只需将其设置为第二个值; （3）将属性设置为其getter返回的值应该没有可观察到的效果; （4）通常，设置属性不应导致任何其他读写属性发生更改，但可能会更改其他只读属性（请注意，大多数违反此规则的行为都会违反＃2和/或＃3，但即使这些规则不会被违反，这些设计似乎仍然可疑。 使一个对象在设计器中可用可能需要给它一些不遵循这些规则的属性，但是不遵循这种语义的运行时更改应该由setter方法完成。
在许多情况下，可能适合使用只读属性和单独的“Set”方法（例如，对于控件的“Parent”属性，这将是我的偏好）。 在其他情况下，具有受一个读/写属性影响的几个相关ReadOnly属性可能是有用的（例如，具有指示控件及其所有父项是否可见的只读属性可能是有用的，但是这样的function不应包含在读写Visible属性中）。