为什么使用带有Java import语句的通配符不好？

使用单个语句更方便,更清晰

import java.awt.*;

而不是导入一堆个别类

import java.awt.Panel;
import java.awt.Graphics;
import java.awt.Canvas;
...

在import声明中使用通配符有什么问题？

1> Benjamin Pol..：

---

唯一的问题是它使你的本地命名空间变得混乱.例如,假设您正在编写Swing应用程序,因此需要java.awt.Event,并且还与公司的日历系统连接,该系统具有com.mycompany.calendar.Event.如果使用通配符方法导入两者,则会发生以下三种情况之一:

你java.awt.Event和之间有一个完全的命名冲突com.mycompany.calendar.Event,所以你甚至无法编译.

你实际上只管理导入一个(只有你的两个导入中的一个.*),但它是错误的,你很难找出你的代码声称类型错误的原因.

当您编译代码com.mycompany.calendar.Event时没有,但是当他们稍后添加一个您之前有效的代码时突然停止编译.

显式列出所有导入的优点是,我可以一目了然地告诉您要使用哪个类,这使得阅读代码变得更加容易.如果你只是做一个快速的一次性事情,没有明显的错误,但未来的维护者将感谢你的清晰度.

---

请务必查看下面的评论 - 随着时间的推移,将类型添加到第三方库中会出现更大的问题.您可以编译代码,在某人将类型添加到您依赖的jar后停止编译.

---

这是将要发生的第一个场景.编译器注意到有两个Event类并给出错误.

---

关于问题1:从技术上讲,你可以编译,但每次都必须使用完全限定的类名.

2> davetron5000..：

---

这是对明星进口的投票.import语句用于导入包,而不是类.导入整个包更干净; 这里发现的问题(例如java.sql.Datevs java.util.Date)很容易通过其他方式弥补,而不是通过具体的进口来解决,当然也不能证明所有类别的疯狂迂腐进口都是正当的.没有什么比打开源文件和必须翻阅100个import语句更令人不安的了.

进行特定的导入会使重构变得更加困难; 如果删除/重命名类,则需要删除其所有特定的导入.如果将实现切换到同一个包中的其他类,则必须修复导入.虽然这些额外的步骤可以实现自动化,但它们确实可以提高生产效率.

即使Eclipse默认不进行类导入,每个人仍然会进行星级导入.对不起,但是进行特定进口确实没有合理的理由.

以下是如何处理类冲突:

import java.sql.*;
import java.util.*;
import java.sql.Date;

---

您提到的所有问题都可以通过现代IDE解决(隐藏导入,重构类名等等).

---

@ davetron5000如果您的代码包含10个以上的通配符导入,并且您使用类`Foo`,并且如果我在不使用IDE的情况下读取您的代码(因为您的论点是我不应该使用它),我怎么知道哪个包'Foo`来自哪里？当然,使用IDE,IDE会告诉我,但你的整个论点是我应该能够*读取*没有一个代码.进行显式导入有助于**记录代码***(避免使用通配符的很好理由)*,而且我更有可能在不使用IDE的情况下阅读*代码,而不是我将*写作*代码不使用IDE.

---

请参阅http://javadude.com/articles/importondemandisevil.html,了解它为什么是邪恶的详细信息.基本思想:当类_added_到您导入的包时,它可能导致代码停止编译(比如将List添加到java.util ...时)

---

我同意.虽然我不反对使用显式导入,但我仍然喜欢使用星型导入.他们强调"重用单位"是整个包装,而不是其个别类型.其他人反对明星进口的原因很弱,而且根据我使用明星进口的经验从未造成任何实际困难.

---

我不应该使用IDE来读取或编写源代码 - 代码应该是可读的,没有特殊工具,除非语言是令人难以置信的脑力.在这种情况下,Java工作得很好 - 只需使用星级导入.没有理由不这样做.

---

可靠的配置管理和持续集成可以轻松解决这个问题,并且您没有浪费代码的显式类名.我同意它的语言设计很差,但是解决这个问题很简单

---

@ davetron5000您不必使用IDE来读取或编写源代码.所有体面的文本编辑器也支持折叠.

---

甚至鲍勃叔叔也建议在他的清洁代码书中进行包装进口.这是我使用它们的充分理由.

---

答案：“导入语句旨在导入软件包，而不是类。” 我的IDE：`[Java]只能导入类型。org.springframework.stereotype解析为包`

---

如果您有一百个进口，那么您的班级可能太大了，可能负责的不只一件事情。这里的问题不是导入，而是糟糕的代码。您应该处理烂掉的东西，而不是像花朵一样漂亮地摆弄它们。;）

---

@ davetron5000您已使自己的论点无效。要使代码“无需特殊工具即可独立阅读”，您必须具有完全合格的导入。使用通配符导入，如果不搜索包或使用IDE悬停帮助，就不会知道类的来源。

3> Scott Stanch..：

---

请参阅我的文章Import on Demand is Evil

简而言之,最大的问题是当一个类被添加到您导入的包时,您的代码可能会中断.例如:

import java.awt.*;
import java.util.*;

// ...

List list;

在Java 1.1中,这很好; 列表在java.awt中找到,没有冲突.

现在假设您签入了完美的代码,一年后其他人将其编辑出来进行编辑,并使用Java 1.2.

Java 1.2在java.util中添加了一个名为List的接口.繁荣!冲突.完美的代码不再有效.

这是EVIL语言功能.有否原因,代码应该停止编译仅仅因为一个类型添加到包...

此外,它使读者难以确定您正在使用哪个"Foo".

---

这不是一个有效的借口.如果您正在更改Java版本,那么如果您更改代码使用的二进制文件的版本,则会出现某些事情失败的情况.在这些情况下,代码会抛出编译错误,并且修复很简单(请参阅上一个答案:http://stackoverflow.com/a/149282/7595)

---

@PabloFernandez - Nope - 如果我查看存储库中已存在一年的代码,它仍然应该编译.当新类被_added_到我导入的现有包时,按需导入很容易失败.升级Java版本不仅仅是一个问题.此外 - 如果API设计得很好,它应该_never_在升级时破坏现有代码.升级java版本时我唯一需要更改代码的原因是因为按需导入以及Sun将XML API拉入Java运行时.

---

我的答案是,这是一个不必要的语言功能,会导致问题.许多IDE /编辑器自动处理导入扩展.使用完全限定的导入,并且不会发生此特定错误.当我在压力下修复现有代码中的错误时,我已经受到了这个问题的打击,你真的不需要像这样的东西来分散手头的真实任务.`java.util.List` vs` java.awt.List`并不算太糟糕,但是当类名是`Configuration`并且多个依赖库已经在最新的maven repo版本中添加它时尝试它.

---

如果我更新一个jar,我使用的类是API向前兼容的,并且我不使用按需导入语法,它根本不会影响我.这对你有意义吗？不要在定义导入时懒惰,这不是问题.按需导入语法是Java语言定义中的一个错误; 合理的语言不应该允许这样的错误.

---

在类路径中添加一个类(具有唯一的,完全限定的名称!)不应该影响任何东西.这里的要点是,如果你_do_not_使用按需导入语法,它就不会.因此,不要使用语言不幸允许的错误语法,这是一个不那么真实的问题,你可以得到.

---

类路径是编译过程的基本组成部分.如果您认为任意更改类路径对您的曾编译代码没有影响,那么您至少可以说是天真的.

4> hwiechers..：

---

这不是不好用通配符与Java导入语句.

在清洁代码中,Robert C. Martin实际上建议使用它们来避免长导入列表.

以下是建议:

J1:使用通配符避免长导入列表

如果您使用包中的两个或更多类,则使用导入整个包

import package.*;

很长的进口清单令读者望而生畏.我们不希望使用80行导入来混淆模块的顶部.相反,我们希望导入是关于我们与哪些软件包协作的简明陈述.

特定导入是硬依赖性,而通配符导入则不是.如果您专门导入一个类,那么该类必须存在.但是如果导入带有通配符的包,则不需要存在特定的类.在搜索名称时,import语句只是将包添加到搜索路径中.因此,这些导入不会产生真正的依赖关系,因此它们可以使我们的模块更少耦合.

有时,特定导入的长列表可能很有用.例如,如果您正在处理遗留代码,并且想要找出构建模拟和存根所需的类,则可以在特定导入列表中查找所有这些类的真正限定名称然后放入适当的存根.但是,这种用于特定进口的用途非常罕见.此外,大多数现代IDE允许您使用单个命令将通配符导入转换为特定导入列表.因此,即使在传统情况下,最好导入通配符.

通配符导入有时会导致名称冲突和歧义.具有相同名称但在不同包中的两个类需要专门导入,或者至少在使用时特别限定.这可能是令人讨厌的,但是很少见,使用通配符导入通常仍然比特定导入更好.

---

我建议Robert C. Martin使用更好的模式来创建更简洁的包和他自己的类,不需要80行导入.在单个类中导入所需的许多类只是乞求'熵,熵,请打破我......'并指出避免导入的原因*在Scott Stanchfields中概述了

---

*很长的进口清单令读者望而生畏.* - 这种说法的推定无效.程序员不需要从上到下阅读源代码.我们可能根本不会阅读导入列表.当我们这样做时,我们可能只读取其中一个进口,以便澄清.在其他时候,如果我们在IDE中工作,导入可能会完全崩溃.无论来源如何,今天这都是不好的建议.

---

尽管我一般都喜欢鲍勃叔叔所说的话,但在这种情况下我也不得不反对他.

---

只是在引用此问题时提供一些平衡:[Google Java风格指南](https://google.github.io/styleguide/javaguide.html#s3.3-import-statements)以及[Twitter的Java风格指南](https://github.com/twitter/commons/blob/master/src/java/com/twitter/common/styleguide.md#no-wildcard-imports)(主要基于谷歌之一,公平地说)明确禁止使用通配符.但他们没有为这一决定提供任何理由.

5> hazzen..：

---

它使您的命名空间变得混乱,要求您完全指定任何不明确的类名.最常见的情况是:

import java.util.*;
import java.awt.*;

...
List blah; // Ambiguous, needs to be qualified.

它还有助于使您的依赖项具体化,因为所有依赖项都列在文件的顶部.

6> 小智..：

---

性能:字节代码相同,对性能没有影响.虽然它会导致一些编译开销.

编译:在我的个人机器上,编译一个空白类而不导入任何东西需要100毫秒,但导入java时相同的类.*需要170毫秒.

---

它有所不同,因为它在编译期间被搜索.

---

`import java.*`什么都不导入.为什么会有所作为？

7> Josh Segall..：

---

它有助于识别类名冲突:不同包中具有相同名称的两个类.这可以用*import掩盖.

它使依赖项显式化,以便以后必须阅读代码的任何人都知道您要导入的内容以及您不想导入的内容.

它可以使编译速度更快,因为编译器不必搜索整个包来识别依赖性,尽管这对现代编译器来说通常不是很大.

使用现代IDE可以最大限度地减少显式导入的不便之处.大多数IDE允许您折叠导入部分,因此它不会妨碍,在需要时自动填充导入,并自动识别未使用的导入以帮助清理它们.

我工作过的大多数使用大量Java的地方都使得显式导入成为编码标准的一部分.我有时仍然使用*进行快速原型设计,然后在产品化代码时扩展导入列表(某些IDE也会为您执行此操作).

8> Jeff C..：

---

我更喜欢特定的导入,因为它允许我在不查看整个文件的情况下查看文件中使用的所有外部引用.(是的,我知道它不一定会显示完全合格的参考文献.但我尽可能避免它们.)

9> 小智..：

---

在之前的项目中,我发现从*-imports更改为特定导入会将编译时间缩短一半(从大约10分钟缩短到大约5分钟).*-import使编译器搜索列出的每个包中与您使用的类匹配的类.虽然这个时间可能很短,但它会增加大型项目.

*-import的一个副作用是开发人员会复制和粘贴常见的导入行,而不是考虑他们需要什么.

---

必须**很多**的进口线或**非常可怜的**开发系统才是真的.我使用import-*我可以在2分钟内编译我的*整个代码库*2107类.

10> Ivan..：

---

在DDD书中

在实现将基于的任何开发技术中,寻找最小化重构模块的工作的方法.在Java中,无法逃避导入到单个类中,但您至少可以一次导入整个包,这反映了包具有高度内聚单元的意图,同时减少了更改包名称的工作量.

如果它使本地命名空间混乱不是你的错 - 责怪包的大小.