令我惊讶的是，在尝试操作类中的字段时应使用C中的Properties。但是，当涉及复杂的计算或者数据库时，我们应该使用getter / setter。

这样对吗？

何时在属性上使用s / getter？

解决方案

回答

如果语言支持属性，则只需使用属性。

回答

这都是个人喜好。当它被编译时，事实证明这是两种方法的getter / setter函数。

在设置和检索成员值时，我个人使用属性，而没有任何副作用。如果检索/保存值有副作用，那么我使用一个函数。

回答

使用属性。 MS的框架设计指南书中的一个有趣注释是，如果我们有一个属性，并且需要为更复杂的set / get添加额外的方法，那么我们应该消除该属性，而只使用get / set方法。

回答

我会说总是问自己哪个更有意义。方法通常被理解为要执行的动作，通常用诸如" open()"，" flush()"，" parse()"之类的措辞来表达。属性往往被理解为更高级的字段/变量" DisplayName"，" AutoSize"和" DataSource"。

我注意到，这往往与自定义控件开发有关。由于它有可能被其他许多未编写它的人使用，并且我们可能不会问这个问题，因此最好采用具有逻辑意义且不会令开发人员感到惊讶的设计。

回答

当值是只写的或者一次要设置多个值时(很明显)，我倾向于使用setter。和我们一样，我的本能也是使用getter和setter作为信号，表明某个进程可能是长时间运行的，产生线程或者执行其他一些不重要的工作。另外，如果setter在类中具有非显而易见的准备工作，我可能会改用getter或者setter，因为人们很少阅读有关属性的文档，并且期望属性始终可以访问。但是即使在这种情况下，我也可以使用属性，如果它有可能使调用代码的读取效果更好。

回答

忘记Getter和Setter方法。只需使用属性。

值得一提的是，属性在程序集中最终以Setter和/或者Getter方法的形式结束。只需一点点元数据，Setter和/或者Getter就可以成为属性。因此，实际上，属性= setter / getter方法。

回答

.NET设计指南在"属性与方法"部分中提供了对该问题的一些答案。

基本上，属性与字段具有相同的语义。我们不应该让属性抛出异常，属性不应该有副作用，顺序不重要，并且属性应该相对较快地返回。如果这些事情有可能发生，最好使用一种方法。该准则还建议使用返回数组的方法。

在决定是否使用属性或者方法时，如果我将其视为字段，则将有所帮助。我考虑了该属性的行为，并问自己："如果这是课堂上的一个领域，如果它的行为方式与我一样，我会感到惊讶吗？"例如，考虑TcpClient.GetStream方法。根据是否建立连接，它可能会引发多个异常，并且在尝试获取流之前，必须先配置TcpClient，这一点很重要。因此，它是Get方法而不是属性。

如果仔细看一下设计指南，就会发现通常不是优先考虑的问题；在某些情况下，有充分的理由使用方法而不是属性。

回答

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

而且它们应该没有副作用。

回答

微软的回答是好的，但是我将为读写属性添加更多规则(微软有时会违反规则，顺便说一句，引起很多混乱)：(1)属性设置器通常不应影响那些不是可读写对象的可观察属性被认为是其属性正在被设置的对象的一部分； (2)将一个属性设置为一个值，然后再将另一个属性设置为使所有受影响的对象保持相同(可观察)的状态，就像将其简单地设置为第二个值一样； (3)将属性设置为其getter返回的值应该没有明显的效果； (4)通常，设置属性不应导致任何其他读写属性发生变化，尽管它可能会更改其他只读属性(请注意，大多数违反此规则的行为都会违反＃2和/或者＃3，但即使这些规则不会被违反，因此此类设计似乎仍然令人怀疑。使对象在设计器中可用可能需要为其提供一些不遵循这些规则的属性，但是不遵循此类语义的运行时更改应由setter方法完成。

在许多情况下，拥有只读属性和单独的" Set"方法(例如，对于控件的" Parent"属性，这是我的偏爱)可能是合适的。在其他情况下，具有几个受一个读/写属性影响的相关只读属性可能是有用的(例如，具有指示控件及其所有父级是否可见的只读属性可能是有用的。功能不应包含在可读写的Visible属性中)。