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