Java是否越来越接受静态导入？

曾经有一段时间，至少在礼貌的社会中，人们普遍认为使用“ 不是 ”一词是不可接受的。 确实，那时（也许直到今天），许多人确实（也确实）认为不是一个真实的词。 尽管这个词并没有 引起争议，并且它的用法仍然经常被认为是不恰当的，但是它似乎正在慢慢地获得普遍认可，并且在使用频率方面也占有一席之地。 一次，“了解更多的人” 有意使用它来强调，但在受欢迎程度方面似乎正在慢慢获得。 在许多方面， J2SE 5引入的静态导入似乎与使用“不是”一词类似。

引用了《 J2SE 5编程语言指南 》中有关静态导入的部分（重点是原始内容的一部分）：“那么，什么时候应该使用静态导入？ 非常谨慎！ ”部分的最后一段描述了何时最好使用静态导入：

那么什么时候应该使用静态导入呢？ 非常谨慎！ 仅当您打算声明常量的本地副本或滥用继承（ Constant Interface Antipattern ）时，才使用它。 换句话说，当您需要频繁访问一两个类的静态成员时，请使用它。 如果您过度使用静态导入功能，它将使您的程序无法读取和不可维护，并使用您导入的所有静态成员污染其名称空间。 代码的读者（包括您，在编写代码几个月后）不会知道静态成员来自哪个类。 从类中导入所有静态成员可能对可读性特别有害； 如果只需要一个或两个成员，则分别导入它们。 通过适当地使用，静态导入可以消除重复的类名样板，从而使您的程序更具可读性。

就像“不是”一词一样，受过良好教育的Java开发人员似乎几乎普遍同意应尽量少使用静态导入。 这里的理由很明显。 首先，官方文件是这样说的。 其次，更重要的是，毫无疑问，过度使用静态导入实际上可能导致可读性差的代码，即使它的代码更简洁。 实际上，过多的静态导入可能会导致冲突 ，从而导致大量使用静态导入的能力丧失。 尽管已经意识到并承认了静态导入的弊端和潜在的滥用，但是Java社区似乎越来越多地使用它。

在编写简单的示例来说明要点时（例如本博客中的帖子），我经常不用打扰使用日志记录框架，而是简单地使用System.out和System.err 。 我不介意假设我的代码中对out任何引用均指标准输出的句柄，而对err任何引用均指标准错误的句柄。 我不打算在任何其他情况下使用out或err ，因此这为简单的代码带来了简洁性，而又不会降低可读性或增加歧义。 这也很像Groovy的写标准输出的方法（尽管不那么简洁）。 您可以在Java静态导入中找到有关此方法的更多详细信息：System.out和err ，在我的文章Static Imports和System.out以及Cay Horstmann的文章中， 您是否正在使用静态导入？

在Java世界中，也许甚至更普遍地使用静态导入以单元测试的名义出现。 几种最流行的面向Java的单元测试框架都鼓励使用静态导入来实现更流畅的测试代码。 JUnit的的断言方法 ， 的Mockito的的Mockito方法 ，以及Hamcrest的匹配器是一些静态导入的使用在Java单元测试世界流行的最明显的例子。

在“ 我不喜欢Java的静态导入”一文中 ，Mark Needham描述了一种情况，我认为许多Java开发商店都在使用静态导入时遇到了这种情况：

在我的上一个项目中，我们最后说在测试代码中允许导入static，因为可以从中导入static方法的地方相对较少，但是当涉及到生产代码时，则需要完全限定的路径。

即使在测试代码中使用静态导入也不是没有问题或争议的。 查找Mockito构造的导入静态语句的StackOverflow线程讨论与使用静态导入相关的一些挫败感。 Needham也解决了这个问题 ：

这种方法的优点是使代码阅读更流畅，但缺点是您无法立即知道方法的位置。 我希望能够通过查看它来告诉代码中发生了什么，以及防止这一切的任何障碍。

到目前为止，我已经研究了Java静态导入与java.lang.System.out调用以及单元测试的结合使用。 这两种情况都不是典型的生产代码案例（在生产中，使用日志记录框架进行记录比标准输出更可取，并且单元测试不是生产代码 ，尽管它们可能随其一起提供）。

哪个用于生产代码的Java框架鼓励使用静态导入可能不太明显。 一个例子是lambdaj 。 lambdaj功能 Wiki页面通过建议使用静态导入开始： 在Lambda类中，所有这些功能都作为静态方法提供，因此使用它们的最佳方法是添加以下导入：

import static ch.lambdaj.Lambda.*;

在您要使用它的类中。

更一般的情况下，使用的Java使用静态导入的是发展的领域特定语言 （ DSL在S） 的Java 。 在许多方面，已经在本文中针对JUnit，Mockito，Hamcrest和Lambdaj讨论过的静态导入的使用是这种更趋向于流畅接口和DSL的普遍趋势的具体示例。

出于充分的理由，我相信大多数Java开发人员对于过度使用和滥用静态导入都持谨慎态度。 但是，在适当的情况下更多地使用静态导入似乎是玩弄这些静态输入并了解它们的正面和负面结果的结果。 JVM脚本语言和其他更简洁（较少仪式）的语言的兴起也可能影响了有关使用静态导入的一般思考 。

必须将流畅接口的驱动力（静态导入的正作用）与使用静态导入相关的维护和可读性成本进行比较。 总的来说，就像我认为“不是”仍然被人们所皱眉，但也许不像以前那样被皱眉，我也认为仍然不鼓励静态导入，但是也许我们作为一个Java社区已经开始了看看情况可能还不错，甚至值得付出代价的积极功能。 我认为没有人认为经常使用它们而不考虑使用它们的上下文是一个好主意。

参考： Java中越来越多地接受静态导入吗？ 由我们的JCG合作伙伴 Dustin Marx在Inspired by Actual Events博客中获得。

翻译自: https://www.javacodegeeks.com/2012/04/are-static-imports-becoming.html