为什么在Java导入语句中使用通配符是不好的?

如果你正在使用一个IDE(这是你应该做的)，并且有比你更多的代码所有者，使用通配符导入是不好的，因为它:

对团队其他成员隐瞒信息 提供给您的只是虚假的好处(使用IDE功能比使用通配符导入更好地解决的事情)

大多数“使用通配符”的支持者都专注于个人:我不想维护列表，我不想看到混乱等等。下面是几个常见的例子:

维护更加困难——当您想要在源代码中引入一个新类时，您必须手动添加import语句 重构更加困难——如果代码被移动了，那么导入语句就必须更新 减少混乱，整理文件内容——这里的目标是“消除干扰”。

These arguments were more convincing before IDEs did all of that automatically. If you're using a plain text editor instead of an IDE, then these arguments have some merit. But if you're using a plain text editor, you are already subjecting yourself to a number of other much more significant inefficiencies, and managing import statements is just one among many things that you should stop doing by hand. IDEs offer automatic management of imports, powerful refactoring tools, and folding (hiding) of any parts of the code you don't want to see.

对于“避免通配符”的支持者，有很多例子，但我只指出一个:

清晰度——特别是当有新人进入代码库时。他们将带着问题来到这里，并在探索代码的过程中继续发现新的问题。对于这个新的代码贡献者，通配符导入语句不能回答任何问题，在最坏的情况下可能会产生混乱、误解和新问题。相反，对于显式导入(并使用IDE)，最坏的情况是中性的:没有提供新的信息;最好的情况是，它不仅可以减少歧义，而且还可以提供答案。

在一天结束的时候，它帮助整个团队降低(尽管是以一种很小的方式)代码的复杂性，减少混乱，增加清晰度。

为什么在Java导入语句中使用通配符是不好的?

如果你正在使用一个IDE(这是你应该做的)，并且有比你更多的代码所有者，使用通配符导入是不好的，因为它:

对团队其他成员隐瞒信息 提供给您的只是虚假的好处(使用IDE功能比使用通配符导入更好地解决的事情)

大多数“使用通配符”的支持者都专注于个人:我不想维护列表，我不想看到混乱等等。下面是几个常见的例子:

维护更加困难——当您想要在源代码中引入一个新类时，您必须手动添加import语句 重构更加困难——如果代码被移动了，那么导入语句就必须更新 减少混乱，整理文件内容——这里的目标是“消除干扰”。

These arguments were more convincing before IDEs did all of that automatically. If you're using a plain text editor instead of an IDE, then these arguments have some merit. But if you're using a plain text editor, you are already subjecting yourself to a number of other much more significant inefficiencies, and managing import statements is just one among many things that you should stop doing by hand. IDEs offer automatic management of imports, powerful refactoring tools, and folding (hiding) of any parts of the code you don't want to see.

对于“避免通配符”的支持者，有很多例子，但我只指出一个:

清晰度——特别是当有新人进入代码库时。他们将带着问题来到这里，并在探索代码的过程中继续发现新的问题。对于这个新的代码贡献者，通配符导入语句不能回答任何问题，在最坏的情况下可能会产生混乱、误解和新问题。相反，对于显式导入(并使用IDE)，最坏的情况是中性的:没有提供新的信息;最好的情况是，它不仅可以减少歧义，而且还可以提供答案。

在一天结束的时候，它帮助整个团队降低(尽管是以一种很小的方式)代码的复杂性，减少混乱，增加清晰度。

郑重声明: 当您添加导入时，您也在指示您的依赖项。

您可以很快看到文件的依赖关系(不包括相同名称空间的类)。

在DDD书中

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

如果它弄乱了本地命名空间，那不是你的错——是包的大小造成的。

请参阅我的文章“按需进口是邪恶的”

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

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

// ...

List list;

在Java 1.1中，这很好;在java中找到列表。啊，没有冲突。

现在假设您检入了运行良好的代码，一年后，其他人使用Java 1.2编辑了它。

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

这是一个邪恶的语言特性。没有理由仅仅因为一个类型被添加到包中就停止编译……

此外，它使读者难以确定您使用的是哪个“Foo”。

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

event和com.mycompany.calendar之间存在完全的命名冲突。事件，因此您甚至无法编译。 您实际上只导入了一个(两个导入中只有一个导入了。*)，但它是错误的，并且您很难弄清楚为什么代码声称类型是错误的。 在编译代码时，没有com.mycompany.calendar。事件，但当他们后来添加一个时，您以前有效的代码突然停止编译。

显式列出所有导入的好处是，我可以一眼看出您打算使用哪个类，这使得代码的阅读更加容易。如果您只是在做一个快速的一次性的事情，那么没有什么明显的错误，但是未来的维护者会因为您的清晰而感谢您。