现实项目中的 Java 包理解

Question

我想了解真正的大型项目中的打包方法。

假设我们有一个包 com.abc.xyz，为此，我们确实有一个像 com/abc/xyz 这样的路径。

是否可以在不同的目录结构中拥有多个相同的包名称，例如:

目录路径1:/home/user1/project/module1/src/java/com/abc/xyz

目录路径2:

/home/user1/project/module2/src/java/com/abc/xyz

最后，当我们为整个项目创建 jar 时，我们是否为 com 目录创建 jar ？

当某些应用程序使用 import com.abc.xyz 时，它如何知道它引用的是哪个目录路径的包？

最后，有没有什么好的书籍/资源提供有关打包、如何将项目划分为模块、包名称等方面的指南。

还有一件事，一个项目是否有像上面例子中那样的通用包基名称:com.abc.xyz(例如 org.apache.hadoop )。

谢谢，维宾

Answer 1

就类加载器而言，在不同源目录中创建的包是同一个包。类文件位于同一个 jar 中还是不同的 jar 中也并不重要。 JVM 不会根据源代码的来源进行区分。(当然，如果您有两个由不同的类加载器加载的 jar，那么它们将得到不同的处理。)

经常有相同包具有不同源代码树的一种情况是，当您在不同目录中进行测试时(使用通常的 Maven 约定，其中代码位于 src/main/java 下，测试位于 src/test/下) java)，但与他们使用的代码具有相同的包。这些测试能够执行被测代码的 protected 和包私有(private)部分，因为它们与该代码位于同一包中。

jar 内的目录路径应从包的根目录开始。 (最顶层的目录应该是/，然后是 com 或 org 或其他目录，等等。)包确实形成了一种树状结构，当您将代码放入文件系统中时，您最终会得到包的层次结构，但是语言它本身不识别“子包”的概念(除了以 java 开头的包是特殊的并且受到类加载器的特殊处理)。

不同的人将代码组织到包中的方式不同。有些人喜欢按层组织代码(将所有 Controller 放在一个包中，将所有服务放在另一个包中，将所有 daos 放在另一个包中)，有些人喜欢按功能组织代码。

分层打包是组织代码的传统方式，这似乎是 Java 社区的首选做法。这样做的一个后果是，当代码将某个功能实现为与包结构成直角的垂直切片时(因为它可能需要新的 Controller 端点，可能需要新的服务方法等)，因此密切相关的代码位相同的功能最终分散在不同的目录中。 The Java Practices website makes an interesting case for package-by-feature :

Package By Feature Package-by-feature uses packages to reflect the feature set. It tries to place all items related to a single feature (and only that feature) into a single directory/package. This results in packages with high cohesion and high modularity, and with minimal coupling between packages. Items that work closely together are placed next to each other. They aren't spread out all over the application. It's also interesting to note that, in some cases, deleting a feature can reduce to a single operation - deleting a directory. (Deletion operations might be thought of as a good test for maximum modularity: an item has maximum modularity only if it can be deleted in a single operation.)

这是一个SO问题asking about package by feature or layer .