我的内部API类应该都在一个包中吗？

Question

我正在努力打包API以供公众使用。因此，我试图限制只暴露于我希望公开和可支持的方法。当然，这有很多有限的访问方法。

问题是我有很多内部代码需要访问这些受限制的方法而不公开这些方法。这会产生两个问题：

• 我无法创建接口 这样在类之间进行通信 会使这些我的内部方法 公开。
• 我无法访问受保护或默认 方法，除非我把大部分 我的内部课程一样 包。

所以，我在干净隔离的包中有大约70或80个内部类，但过度允许的访问修饰符。你会说单个包是两个邪恶中的较小者，还是有更好的方法来掩盖我的内部方法，同时保持更细粒度的包？

我有兴趣在这里找到最佳实践。

我已经知道This

了

Answer 1

您的问题有两种解决方案，不涉及将所有类保留在同一个包中。

第一种是使用（Practical API Design，Tulach 2008）中描述的Friend Accessor / Friend Package模式。

第二种是使用OSGi。有一篇文章here解释了OSGi如何实现这一目标。

相关问题：1，2，3和4。

Answer 2

一个例子可能是Servlet API，因为你看到它们将公共servlet API和http分成两个包。

如果您在api.jar和implementation.jar中分隔代码，则可以使用api.jar用户无法看到的实现接口。 如果类的对象不管它们的包，都必须以任何方式进行协作，那么这些方法当然必须是可见的（至少在实现中）。

Answer 3

是的，你无法保护内部实现的东西不被访问。有些技术（如OSGi）在运行时/应用程序启动期间提供了解决方案。这是一个java语言设计模块化缺陷（但由于兼容性下降，之后也很难添加）。

我喜欢将公开可见的工件添加到 / api 包和内部到 / internal 的约定。最后你最终得到了。

# this package is allowed to be accessed by api-users
com.foo.users.api
# this is completely internal logic (api implementation)
# should only be touched by the api-module itself.
com.foo.users.internal

通过这种方式，您可以进行清晰的分离，还可以运行静态代码分析代码规则。

与上面提到的servlet-api一样，您甚至可以将api与impl进一步分解为不同的jar。但是这需要更多的努力来构建生命周期和维护模块，所以我只会在完整的运行时工件拆分有意义的地方（比如在jsr-spec和impl中）。