Java避免重复导入(不是继承导入)

Question

我已经搜索过，但没有发现任何关于这个真正令人讨厌的问题:

在我制作的每个类(class)中，我都必须导入一大堆文件，以便能够经常使用一些任意代码。更烦人的是我必须一遍又一遍地导入自己的类，每个其他类都导入，导致困惑。想象一下一个大项目!

有了 Eclipse(我正在使用的)折叠功能和自动组织功能，它是一个蹩脚的贫民窟解决方案。另外 Eclipse 不能总是说要导入什么文件，我必须查找它并手动添加它。所以我说我对 Java 和 Eclipse 太菜鸟了，我一定是错过了真正的方法。请与我分享。

我已经搜索并找到了有关“继承导入”的问题，但我对使用父类(super class)/子类导入的问题一点都不感兴趣。我所追求的是以某种方式链式导入文件。事情很简单:如果 file_b 从 file_a 导入，file_c 从 file_b 导入，我发现常识认为指定 file_c 从 file_a 导入是多余的。

更好的是，将无处不在的代码放在一个文件中，该文件会在所有其他文件中静默导入(例如从特定路径自动包含)。我再说一遍:我是初学者，我不知道该怎么做，所以请告诉我，即使它看起来很基础。

毕竟，编译器可以很好地将所有代码放入一个大文件中，但我自己并没有放入它，因为代码方式在视觉上更易于理解，每个类都有自己的文件。

提前谢谢你。

编辑:我现在对正在发生的事情有了更清晰的了解:

• 包树被展平，因此“子包”(子文件夹)被视为处于同一级别

• 必须在每个文件中导入外部组件，即使在同一个包中(始终)；

• 如果在同一个包中(一般情况下)，则不必导入；

• 如果要(始终)使用 own.field，则必须静态导入 owns，以便在访问方面将自己类的主体视为相对于实际类的新包。

谢谢大家的澄清。这些有用的信息让我学到了新东西。

我希望有这些 Eclipse 特性，不过:

• 实际使用包的树结构；如果有人做了一个分包，那是因为他从依赖的角度考虑。这里有点封装原则。否则，用户会将所有包放在同一个文件夹中，这样它们会更显眼，也不会产生误导。

• 静态导入目前需要反复指定，打破了免同包导入的逻辑。因此，为要导入的静态类创建一个类似“透明”的限定符，这表示该类将默认静态导入，这将解决整个问题。

Answer 1

恐怕 Java 就是这样。

你基本上有 3 个选择:

• 使用显式单类导入
• 使用包中类的显式“星号”导入
• 组织包，使相关类在同一个包中，不需要导入。

没有其他“自动导入”或导入包含机制。

---

我只想指出，大多数经验丰富的 Java 程序员不会和您一样烦恼。事实上，大多数开发人员只是使用 IDE 提供的工具来添加/删除/组织导入……并默认将它们折叠起来。

你会习惯的。您别无选择。

... it's a lame ghetto solution

是的，好吧，您有权发表自己的意见。大多数人只会说“它工作得很好”......

---

就其值(value)而言，我认为“明星”导入(类)不是一个好主意。考虑这个例子:

import java.io.*;
import com.other.io.*;  // Some 3rd-party library

public class MyClass {
    ...
    private static File = ...
    ...
}

假设我开发这段代码时，只有一个File类 ... 在 java.io .但是假设几年后，com.other 的维护者库推出了一个新版本，该版本定义了一个名为 com.other.io.File 的新类.

• 如果我重新编译 MyClass针对新版本的库，我现在会遇到编译错误。
• 如果我不重新编译，我仍然可以运行现有的 MyClass.class (使用更新的库)，但我的源代码将不再反射(reflect)假设的现实。 (理论上，我必须知道代码何时被编译才能理解File指的是什么。)

将此与显式导入 java.io.File 进行对比.无论第 3 方库维护者做什么，这总是完全它所说的意思。

简而言之，使用“星号”导入意味着其他人可以通过对 3rd 方库进行无害且看似无关的更改来“破坏”我的代码。它们使我的代码脆弱。

那我为什么要提到这个呢？因为我认为自动导入和其他“修复”Java 导入的尝试有可能具有相同的效果……甚至更是如此!