getter和setter被过度使用

我见过数百万人声称公共字段是邪恶的，所以他们将它们设置为私有字段，并为所有这些字段提供getter和setter。我相信这与公开字段几乎是一样的，如果你使用线程(但通常不是这样)或如果你的访问器有业务/表示逻辑(至少有些“奇怪”)，可能会有点不同。

我不赞成公共字段，但反对为每个字段创建getter/setter(或Property)，然后声称这样做是封装或信息隐藏……哈!

更新:

这个答案在评论中引起了一些争议，所以我会试着澄清一下(我不会动原文，因为这是许多人点赞的)。

首先，任何使用公共场地的人都应该坐牢

现在，创建私有字段，然后使用IDE为每个私有字段自动生成getter和setter，几乎和使用公共字段一样糟糕。

很多人认为:

私有字段+公共访问器==封装

我说(自动或非自动)为字段生成getter/setter对有效地违背了您试图实现的所谓封装。

最后，让我引用Bob叔叔在这个主题中的一句话(摘自“干净代码”的第6章):

我们保持沉默是有原因的 私有变量。我们不想要 没有人可以依靠他们。我们想要的 自由地改变他们的类型或者 心血来潮地执行 冲动。那么，为什么要这么多呢 程序员会自动添加getter 和对象的setter，暴露 他们的私人领域，就好像他们是 公众吗?

I'd say that my most controversial opinion on programming is that I honestly believe you shouldn't worry so much about throw-away code and rewriting code. Too many times people feel that if you write something down, then changing it means you did something wrong. But the way my brain works is to get something very simple working, and update the code slowly, while ensuring that the code and the test continue to function together. It may end up actually creating classes, methods, additional parameters, etc., I fully well know will go away in a few hours. But I do it because i want to take only small steps toward my goal. In the end, I don't think I spend any more time using this technique than the programmers that stare at the screen trying to figure out the best design up front before writing a line of code.

我得到的好处是，我不必不断地处理那些因为我碰巧以某种方式破坏了它而不再工作的软件，并试图找出停止工作的原因和原因。

如果你是一个开发人员，你应该会写代码

去年我做了很多面试，在我的面试部分，我应该测试人们的思维方式，以及他们如何在白板上实现简单到中等的算法。我一开始的问题是:

假设可以使用函数4 *(1 - 1/3 + 1/5 - 1/7 +…)来估计圆周率，使用更多的项来获得更高的精度，编写一个计算圆周率的函数，其精度为小数点后5位。

这是一个应该让你思考的问题，但对于一个经验丰富的开发人员来说不应该是遥不可及的(它可以用大约10行c#来回答)。然而，我们的许多候选人(应该是中介机构预先筛选的)甚至无法开始回答这个问题，甚至无法解释他们将如何回答这个问题。所以过了一段时间，我开始问一些更简单的问题，比如:

给定圆的面积是π乘以半径的平方，写一个函数来计算圆的面积。

令人惊讶的是，超过一半的候选人不能用任何语言编写这个函数(我可以阅读大多数流行的语言，所以我让他们使用他们选择的任何语言，包括伪代码)。我们有“c#开发人员”，他们不能用c#编写这个函数。

我对此感到很惊讶。我一直认为开发人员应该会写代码。现在看来，这似乎是一个有争议的观点。当然是在面试中!

编辑:

在评论中有很多关于第一个问题是好是坏的讨论，以及你是否应该在面试中问这么复杂的问题。我不打算在这里深入研究这个问题(这是一个全新的问题)，除了说你在很大程度上错过了文章的重点。

是的，我说过人们在这个问题上无法取得任何进展，但第二个问题很琐碎，许多人在这个问题上也无法取得任何进展!任何自称为开发人员的人都应该能够不假思索地在几秒钟内写出第二个问题的答案。很多人做不到。

手动停止程序是一种有效的、经过验证的查找性能问题的方法。

可信吗?对大多数人来说并非如此。真的吗?绝对的。

程序员的判断比必要的要多得多。

看看这些帖子中所有被认为是“邪恶”或“可怕”的事情吧。

程序员喜欢数据结构。

见证所有关于类、继承、私有与公共、内存管理等以及如何分析需求的讨论。

我认为使用try/catch异常处理比使用简单的返回代码和相关的公共消息传递结构来传递有用的错误消息更糟糕。

用try/catch块乱扔代码不是解决方案。

只是将异常传递到堆栈上，希望上面的内容会做正确的事情或 生成信息错误并不是解决方案。

认为您有机会系统地验证适当的异常处理程序可以解决透明对象或opague对象中可能出现的任何错误，这是不现实的。(还要考虑到后期绑定/外部库以及随着系统的发展，调用堆栈中不相关函数之间不必要的依赖关系)

返回代码的使用很简单，可以很容易地系统地验证覆盖范围，如果处理得当，就会迫使开发人员生成有用的错误消息，而不是太常见的堆栈转储和模糊的I/O异常，即使对最聪明的最终用户来说，这些异常也“异常”毫无意义。

--

我最后的反对意见是使用垃圾收集语言。不要误会我的意思。在某些情况下，我喜欢它们，但在服务器/MC系统中，它们在我看来没有位置。

GC并不是绝对正确的——即使是设计得非常好的GC算法也可能基于依赖关系图中不明显的循环引用而在对象上停留太长时间，甚至永远停留。

遵循一些简单模式并使用内存计算工具的非GC系统不会有这个问题，但在设计和测试方面需要比GC环境做更多的工作。这里的权衡是，在非GC测试期间，内存泄漏非常容易发现，而找到与GC相关的问题条件则要困难得多。

内存是便宜的，但当你泄露昂贵的对象，如事务句柄、同步对象、套接字连接……在我的环境中，如果不对软件描述进行重大的基本更改，那么您可以坐下来让语言为您操心，这种想法是不可想象的。

好吧，我说过我会更详细地阐述我的“密封类”观点。我想有一种方法可以展示我感兴趣的答案，那就是给我自己一个答案:)

意见:在c#中，默认情况下类应该是密封的

推理:

There's no doubt that inheritance is powerful. However, it has to be somewhat guided. If someone derives from a base class in a way which is completely unexpected, this can break the assumptions in the base implementation. Consider two methods in the base class, where one calls another - if these methods are both virtual, then that implementation detail has to be documented, otherwise someone could quite reasonably override the second method and expect a call to the first one to work. And of course, as soon as the implementation is documented, it can't be changed... so you lose flexibility.

C# took a step in the right direction (relative to Java) by making methods sealed by default. However, I believe a further step - making classes sealed by default - would have been even better. In particular, it's easy to override methods (or not explicitly seal existing virtual methods which you don't override) so that you end up with unexpected behaviour. This wouldn't actually stop you from doing anything you can currently do - it's just changing a default, not changing the available options. It would be a "safer" default though, just like the default access in C# is always "the most private visibility available at that point."

通过让人们明确表示他们希望人们能够从他们的类中派生，我们将鼓励他们更多地思考这个问题。这也可以帮助我解决我的懒惰问题——虽然我知道我应该密封几乎所有的类，但我很少真的记得这样做:(

对方观点:

我可以看到这样一种说法:可以相对安全地派生没有虚方法的类，而不需要额外的灵活性和通常需要的文档。目前我不确定如何应对这个问题，只能说我相信意外打开类的危害比意外密封类的危害更大。