为什么要分离 API 定义和实现 JAR

Question

对于 jstl 标签，提供了一个 API javax.servlet.jsp.jstl-api-1.2.1.jar 和实现 javax.servlet.jsp.jstl-1.2.1.jar。

对于 servlet，提供了 servlet-api.jar 中的 API 和来自 tomcat 或 GlassFish 的实现 jar。

对于集合，提供java.util.List 等API 和java.util.ArrayList 和java.util.LinkedList 等相应实现。

IDE Netbeans 是另一个例子。

1. 实现 jar 包括 API（主要是接口）及其实现，为程序员/开发人员提供使用 API JAR 及其相应实现（单独的 JAR）的解决方案有什么优势？

2. 对于使用 java 开发企业应用程序，提供 API 是否是开发人员之间稳定合同的标准方法？

Answer 1

我在我的 Practical API Design 书中主张将 API 与其实现分开。当时我看重simple library 和modular library 方法。我们在设计NetBeans Platform API 时成功地使用了它们。当谈到vendor library 风格时，我通常会感到不安——这是 Java EE 世界中常用的一种方法。

后来我意识到最佳解决方案取决于所需的接近度（请参阅我的detailed explanation）。简而言之，这取决于 API 作者与实现 API 的人的相关程度。是同一个人吗？是否是一组坐下来就规范达成一致？它们是否不同，但我们希望库的用户比实现它的用户多？还是我们希望几乎每个用户都实现（在）库中的东西？那么这个问题的答案就是：

• 无对多
• 一对多
• 少对多
• 多对多

Proximity 分类。在某些情况下，它们中的每一个都可以派上用场。然而，我一直最喜欢的是具有全功能modular library 设计的多对多方法。

Answer 2

1) 如果您将 API 放在不同的 jar 中，那么您可以让无法访问实现的客户端使用它。例如：

• 您可以从客户端的编译时类路径中排除实现，以确保 API 的客户端不需要任何特定的实现。

• 您可以从 API 客户端的运行时类路径中排除实现（通过像 servlet 那样的类加载器或单独的 JVM），这样客户端就不能依赖任何特定的实现，和 em> 以便他们可以使用与实现使用的库发生冲突的库。

2) 不是真正的个人开发人员，但通常使用这样的策略来避免不同开发团队之间的冲突和不必要的依赖关系。

Answer 3

这是因为只有 API 是标准化的，并且有多种实现是可能的，并且API 是一个不完整的规范。对于 servlet，除了 Web 应用程序使用的 servlets API 之外，还有 Web 应用程序服务器（Tomcat 或 Glassfish）。应用程序服务器是一个大型程序，具有许多其他功能和 API。对于 Web 应用程序，您的 servlet 不是“程序”；应用服务器是。并不是您的 servlet 委托给服务器，而是服务器委托给您的代码（在 WAR 中）。

Answer 4

在使用实现进行编程时，您可能还需要 API 规范（接口、抽象类等）。

Interface obj = new ClassImpletingInterface();

也可以这样做

ClassImpletingInterface obj = new ClassImpletingInterface();

如果您的程序只使用后者，那么您可能只使用不包含 API 包的实现 jar。尽可能使用前者以获得更好的可维护性等。现在的问题是为什么不能将 API 包捆绑到实现 jar 中 - 一个 API 一个 jar。可能听起来很简单，但可能并不理想。您可能更喜欢使用从真实来源获得的javax.servelet.jsp.jstl-api 包；未捆绑在 com.newbie.servlet-0.0.1.jar 中。可能存在阻止这种捆绑的法律方面。此外，实现不一定提供完整规范的功能。您对 API 的导入可能来自作为不同部分的两个不同实现，它们可能用于规范的不同版本级别。在这种情况下，可能很少见，每个捆绑不同版本级别的 API 可能会导致麻烦，因为目录中的 jar 搜索没有完全定义。因此，将 API 和实现捆绑到单独的 jar 中会更干净。