空调吸气和排气_吸气剂和二传手被认为有害

空调吸气和排气

Java程序员习惯性地用“ getters”和“ setters”来修饰类，这种做法根深蒂固，以至于几乎没有人质疑为什么这样做或是否应该这样做。最近，我认为最好不要这样做，并且我开始在编写的Java代码中避免使用它。在这篇博客文章中，我将解释原因。但是首先，要进行快速的历史课程。

JavaBeans

Getters和setters起源于JavaBeans规范，该规范最初于1996年末发布，并于1997年8月更新为1.01版。最初的想法是使对象的创建成为可能，这些对象可以用作构建模块来组成应用程序。这个想法过去了，“用户”可以使用某种构建器工具连接在一起，并自定义一组JavaBeans组件以一起充当应用程序。例如，AWT应用程序中的按钮将是Bean（AWT是Java UI库Swing的前身）。另外，一些JavaBeans更像是常规应用程序，然后可以将它们组合成复合文档，因此电子表格bean可以嵌入到网页内。

当遵循以下约定时，对象就是JavaBean：

它必须具有一个零参数的构造函数，该构造函数不能失败。
它具有可通过“ getter”和“ setter”方法访问和更改的属性。
对于称为Foo的bean的任何属性，访问器方法必须称为getFoo 。在布尔属性的情况下，可以将吸气剂称为isFoo 。
Foo的setter方法必须称为setFoo 。
Bean不必为每个属性都同时提供一个getter和一个setter：一个具有getter而没有setter的属性是只读的；具有setter且没有getter的属性是只写的。

该规范描述了许多不同的用例，但是从上面的描述可以清楚地看出，JavaBeans被视为具有行为的对象，而不仅仅是数据包。这个想法已经淡出人们的视线，但是尽管JavaBean被很大程度上遗忘了，但是Java中的getter和setter方法的惯用法仍然存在。

隐喻是错误的

“获取”和“设置”的概念似乎很自然，但这是否正确？ JavaBeans约定使用“ get”来表示查询，这是一个没有副作用的操作，但在现实世界中，getting是一个会改变状态的动作：如果我将一本书下架，则该书不再上架。您可能会反对，这只是纯粹的学问，但我认为这种误解会鼓励我们错误地思考我们编写对象以进行交互的方式。例如，如果我们有一个Thermometer类，那么大多数Java开发人员都会编写代码来读取温度，如下所示：

Temperature t = thermometer.getTemperature();

确实，“获取”温度是温度计的工作吗？没有！温度计的作用是测量温度。我为什么要为此努力呢？这是因为“获取”是必要的陈述：它是温度计的一项操作说明。但是我们不想指示温度计在这里做任何事情；它已经在做它的工作（测量温度），我们只想知道它的当前读数是多少。阅读是由我们完成的。因此，以这种方式编写时，代码更加自然：

Temperature t = thermometer.reading();

我认为这更好地将责任归于责任。但是请务必考虑是否需要访问器，因为…

对象不是数据结构

用getter和setter编写类的习惯对我们的编码方式有微妙的影响。它自然化了我们应该进入对象以获取所需数据，对其进行处理，然后使用结果更新对象的想法，而不是让对象自己执行处理。换句话说，它鼓励我们将对象视为数据包。我们通过getter提取数据，并通过setter更新它们。同时，对数据进行操作的代码位于其他位置。

如果我们的编码习惯使我们倾向于将对象视为纯数据结构，那么ORM框架会积极地实施它。更糟糕的是，如果您使用的是Spring框架–如果您是Java开发人员，那么很有可能–默认情况下，它会将所有bean创建为单例。（令人困惑的是，Spring bean与JavaBeans无关）。因此，现在您有了一个由单例对象组成的系统，该系统在无行为的数据结构上运行。如果您将代码和数据分开听起来像是您所熟悉的编程风格，那您就没错：我们称其为过程编程。

考虑一下这是否是一件好事。毕竟，Java应该是一种面向对象的编程语言。 OO的一大优点是我们可以编写对象类，其名称和交互作用反映问题域。它使我们能够编写要解决的问题的代码，而不会模糊基本编程结构和原始数据类型背后的全局。它帮助我们透过树林看木头。我们不应该放弃这一点。

该怎么做

尽可能停止编写get and set！有时这是适当的做法，但一定要停止使用IDE的功能来为您生成getter和setter。这只是快速执行错误操作的便捷方法。如果需要在对象上公开某个属性，只需将其命名为该属性，然后还要检查是否确实需要公开该属性。询问为什么要这样做。可以将任务委派给对象本身吗？例如，假设我有一个表示货币金额的类，并且希望对一堆交易进行汇总：

Amount total = new Amount(transactions.stream().map(Transaction::getAmount).mapToDouble(Amount::getValue).sum());

代替getValue访问器，为什么不给Amount类一个add()方法并让它为我求和呢？

Amount total = transactions.stream().map(Transaction::getAmount).reduce(Amount.ZERO, Amount::add);

这带来了好处–也许您对使用双精度表示货币金额的想法很感兴趣。没错，BigDecimal会更好。第二个示例使此问题更易于修复，因为内部表示形式得到了更好的封装。我们只需要在一处更改它。

也许您想要获取对象的数据以测试其是否等于某物。在这种情况下，请考虑在对象上实现equals()方法，并为您测试是否相等。如果使用Mockito创建间谍，则无需使用参数捕获器：相反，您可以创建一个等值的对象作为示例，并将其直接传递给verify语句进行比较。

有时您必须创建访问器。例如，为了将数据持久存储在数据库中，您可能需要访问数据的原始表示形式。您是否真的必须遵循获取/设置命名约定？如果您的回答是“这就是用Java完成的方式”，那么我建议您回头阅读JavaBeans规范。您是否真的在编写JavaBean以按照规范描述的方式使用它？您是否正在使用期望您的对象遵循约定的框架或库？

必须创建变种器的次数将减少。函数式编程现在正像一股狂潮一样席卷整个行业，而不变数据的原理是一个很好的原则。它也应该应用于OO程序。如果没有必要改变状态，你应该考虑有必要不改变状态，所以不用加一个赋值函数方法。当您编写导致出现新状态的代码时，将尽可能返回新实例来表示新状态。例如，BigDecimal实例上的算术方法不会更改其自己的值：它们返回表示其结果的新BigDecimal实例。如今，我们拥有足够的内存和处理能力，可以使这种编程方式变得可行。而且Spring框架不需要注入依赖方法的setter方法，它也可以通过构造函数参数进行注入。实际上，这种方法是Spring文档推荐的方法。

某些技术确实要求类遵循JavaBeans约定。如果您仍在为视图层编写JSP页面，则EL和JSTL期望响应模型对象具有getter方法。用于将对象与XML进行序列化/反序列化的库可能需要它。 ORM框架可能需要它。由于这些原因而被迫编写数据结构时，建议您将其隐藏在体系结构边界后面。当对象泄漏到您的域中时，不要让这些数据结构伪装。

结论

在与使用其他语言工作的程序员交谈时，我经常听到他们批评Java。他们说“太罗y”或“样板太多”之类的话。 Java当然有其缺陷，但是当我更深入地询问这些批评时，我通常会发现它们针对特定的实践，而不是针对该语言的任何内在实践。做法不是一成不变的，它们会随着时间的流逝而发展，不良做法可以得到解决。我认为在Java中随意使用get和set是一种不好的做法，如果放弃，我们会编写更好的代码。