魔术笔反选

设置者和获取者是邪恶的。 创建JavaBean定义时，这似乎是个好主意。 但是它们对Java社区造成了很大的伤害。 通常不如null指针那么多，但足够了。

首先，许多初级人员相信实现setter和getter（嘿，在Eclispe中只需单击几下）确实可以正确封装。 我应该详细说明为什么不这样做吗？

另一件事是使用setter和getter反对YAGNI。 YAGNI代表您不需要它 。 这意味着您不应该开发该项目现在不需要的代码。 要强调的是这个词吧 。 许多程序员倾向于开发扩展实际功能并执行比实际需要更通用的代码。 即使从原则上讲它可能是有价值的：在大多数实际情况下却没有。 代码变得更加复杂，另一方面，项目从未发展到需要程序员创建泛化的阶段。

Setter和getter是YAGNI的一个干净，简单且使用非常广泛的示例。 如果setter除了设置字段的值外什么也不做，而getter除了返回字段的值外什么都不做，那为什么我们根本不需要它们呢？ 为什么不将字段的访问修饰符更改为setter和getter的值（可能是public ）？

答案通常是，您可能需要在getter或setter中实现一些更复杂的功能，然后不必更改bean提供的“接口”。 “ 您可能需要实施 ”一词表明这是YAGNI。 而且，这很危险。 实施setter和getter隐式公开了类的实现。 塞特犬做什么？ 设置字段的值。 例如， setBirthDate()通过定义来设置字段birthDate 。 这就是编写调用setter的代码的用户会考虑的方式。 您可以在JavaDoc中记录setBirthDate()实际上“指定”了出生日期，但为时已晚。 您将方法命名为设置方法，仅此而已。 没有人阅读JavaDoc。 API规则。

以后，当您更改代码时， setBirthDate()不仅设置生日，甚至不设置生日，也不会通知用户。 更改是无声的，您只是更改了隐式提供给用户的界面。 会有bug，调试会话，新版本，这很好，因为这会创建工作场所（请讽刺，请）。 如果为用户提供对字段的直接访问，则将字段从public移到private访问修饰符的后面将导致编译时错误。 也许这只是一种怪异的个人喜好，但我更喜欢编译时错误而不是错误。 它们更易于修复（阅读：更便宜）。

不用担心：您仍然可以修改您的API。 您仍然可以从方法集中删除setter和getter，并迫使其他程序员修复其代码，这些代码隐含地假定setter确实已设置并且getter得到。 拜托

我写这篇文章的真实故事是什么？

从前，有一个物体可以做某事。 要执行其任务，您可以设置字段aaa或字段bbb ，但不能两者都设置。 该应用程序是通过这种方式开发的，并且已经超过六年了。 有一天，一位年轻的程序员公主骑着白马，希望使世界变得更美好。 他想使前面提到的类更安全，并修改了setter setAaa()以使字段bbb null ， setAaa() 。 单元测试大放异彩。 覆盖率为100％。 （我应该学会不撒谎。）他提交了图书馆的新书，几周后他完成了实习，回到学校。 那时应用程序开始使用该库的新版本。 由于这一微小的更改，他们惨遭失败，并回滚到了旧版本。 我们所有人都辛苦了，总而言之，由于简单的更改，公司花了大约一年的时间来工作，更不用说程序员从头顶拔下来的头发了。

为什么程序失败了？ 有一些代码以如下方式克隆了包含字段aaa和bbb的对象：

BadBean newBadBean = new BadBean();newBadBean.setAaa(oldBadBean.getAaa());newBadBean.setBbb(oldBadBean.getBbb());

你明白了。 在新bean中，字段aaa始终为null 。

现在您已经阅读了本文，您将永远不会尝试创建一个聪明的二传手。 我知道你不会！ 您知道的一句话是： 始终编​​码，就像最终维护您的代码的人是知道您的住所的暴力精神病患者。 看哪！

翻译自: https://www.javacodegeeks.com/2015/03/the-magic-setter-antipattern.html

魔术笔反选