在C#中编写getter/setter方法有什么问题吗？

Question

我是一个Java，几乎所有我的编程(至少在工作场所)，但我做一些统一的乐趣。我多次使用C#属性，它们仍然可以方便地提供封装，而不必编写getter和setter方法。

尽管如此，为字段编写实际的getter和setter方法(除了我的时间以外)有什么缺点吗？假设这是我的个人统一代码中的乐趣，而不是任何类型的工作或共享的开发环境。

Answer 1

C#属性由方法组成。因此，通过使用方法而不是属性，您不会获得任何运行时优势。

相反，这将涉及开发人员的生产力和代码的可读性。

可读性也适合你自己。几个月后，当您忘记了代码的细节时，您需要修改它以修复bug或添加新特性。即使您不关心这一点，您也可能关心使用相同数量的代码来做更多的事情。

在生产力方面，我们有这样的优势:需要编写更少的代码。如果我们谈论的是汽车产业的话。关于可读性，它们可以减少冗长的代码(减少Get、减少Set和减少())。

属性也可能影响可发现性。由于具有getter和getter，将导致与同一字段关联的方法在intellisense中被分隔。

然而，对于方法有一些争论。例如，如果设置值可能失败，则可能需要使用方法并返回bool，以便在集合失败时可以与调用方通信。理论上说，你可以用一种财产.毕竟，调用方可以在设置属性后读取该属性，以检查是否设置了该值。然而，返回bool是一个线程安全的就绪API。

另一种情况是，属性必须进行长时间的计算才能返回值。使用一种方法意味着它在幕后做一些事情。类似地，使用方法而不是属性可以表示读取值可能会产生副作用(它不是纯的)。增编:这并不是一条硬性规定。然而，一般来说，一种方法可以做一些事情，它是一种行动。另一方面，我们希望能够在任何时候读取属性，而不会产生重大后果。

最后，如果您有一个返回数组的属性，则索引器可能会忽略它。最好是提供一个实际的索引器，或者使用一种方法来避免混淆。

顺便说一句，创造了面向对象术语的艾伦·凯不喜欢策划人。相反，应该封装状态。他说：

很多所谓的面向对象语言都有setter，当对象上有setter时，就会将其转换回数据结构。

对于Alan来说，让第三方意外地改变对象的状态是个坏主意。

考虑到这一点，让met告诉您几个案例，其中属性是一个糟糕的设计：

1. 避免提供属性作为决定要做什么的手段。调用方代码不应该必须读取对象的属性才能决定调用哪种方法。相反，将该逻辑封装在类的方法中。也就是说，对于面向对象的设计，更喜欢Tell，不要问。
2. 避免更改方法行为的属性。如果有它们，您将得到备份属性值、更改值、调用方法、然后还原值的代码。相反，将该值作为参数添加到方法中(即使需要将其添加到类中的几乎每个方法)。这使得使用API更加容易，遵循最少惊讶的原则，对于线程安全的代码更好。

属性，特别是只读属性，对于日志记录和调试仍然非常有用。此外，还有一些东西依赖于属性才能工作，例如某些形式的序列化和数据绑定。

Answer 2

请记住，属性是“实际的getter和setter方法”。属性只不过是一两种方法，还有一条元数据，上面写着“这是一个属性”。调用属性方法的语法不同于调用普通方法的语法，但除此之外，属性方法的工作方式与任何其他方法完全相同。

上面说..。

尽管如此，为字段编写实际的getter和setter方法(除了我的时间以外)有什么缺点吗？假设这是我的个人统一代码中的乐趣，而不是任何类型的工作或共享的开发环境。

用你自己的个人密码？不，不是真的。

主要的缺点是，当其他人阅读您的代码时，他们可能会对正在发生的事情产生错误的理解。如果你写deflection = surface.Deflection，我会猜到找到偏转值是快速而容易的。如果您编写了deflection = surface.GetDeflection()，我会猜到找到偏转值涉及到一些缓慢或困难的事情，比如读取文件，或者与传感器通信以确定偏转。

换句话说，编写getter和setter的通常方法是将它们编写为C#属性，所以如果您不将它们作为C#属性来编写，人们就会假设您有特定的理由不这样做。

当然，如果您以后将C#作为团队的一部分编写，团队可能会希望您以“正常”的方式编写getter和setter，因此您可能希望现在就养成这种习惯。

但是，如果您宁愿读和写controller.SetProcVar(aircraft.GetAttitude().GetBankAngle())而不是controller.ProcVar = aircraft.Attitude.BankAngle，那么这不会给您带来任何意外的问题。