我总是在创建包时怀疑，我想利用包限制访问但同时我想将类似的类划分为包。 当您了解 Java 中的包不是分层的时，问题就来了：
起初，包裹似乎是 分层的，但它们不是。 source
想象一下，我在 foo.bar 上定义了一个 API，它的类是公开的，只有 API 客户端需要的类是公开的。然后我有另一个包，其中包含我在 foo.bar.pojos 定义的 API 中需要的一些内部对象，这些类需要是公共的，以便 foo.bar 可以访问它们，但这意味着 API 客户端也可以访问它们，如果包foo.bar.pojos 已导入。
应该遵循的共同包政治是什么？
【问题讨论】：
一团糟。
仅使用 Java 本身提供的功能，您必须将所有内容放在同一个包中。您最终会得到一个（或几个）包含许多类的包，并且没有为自己分组它们的好方法（但至少该问题不会泄漏到外部）。但是，大多数人不会这样做，因此，您（作为这些库之上的开发人员）的公共类路径中充斥着您永远不需要看到的东西。
您可能喜欢 OSGi，它具有（并强制执行）捆绑私有包的概念。那些不出口到外面的世界。
【讨论】：
我见过两种做法。
第一个是将公共 API 和内部类分成两个不同的工件（jar）。文档也是分开的，因此最终用户很容易区分什么是内部的，什么不是。但有时拥有两个 jars、两个源代码树等会使事情变得更加复杂。
第二个是交付一个 jar，但有一个很好的文档，可以知道什么是内部的，什么不是内部的。文本文档可以解释如何使用 API（从而避免谈论内部）。并且 javadoc 可以指定一个类供内部使用，因此可以更改。
【讨论】：
是的，Java 包不能让您对依赖项进行足够的控制。解决这个问题的经典方法是将外部 API 放在一个包中，将内部实现类放在另一个包中，并依靠人们的良好意识来避免对后者产生依赖。
使用 Maven 和 OSGI，您有一个额外的机制来管理模块/包包之间的依赖关系。在 OSGI 的情况下，您可以显式声明一些包为未导出，并且一个支持 OSGI 的开发环境将防止人们创建有害的依赖项。 Maven 的模块支持较弱，但至少控制了依赖周期。
最后，您可以使用自定义 PMD 规则来强制执行项目的模块化约定......就像有规则阻止对 Java 的“com.sun.*”包树的依赖一样。
【讨论】：