Java的API计划实践

相识在计划Java API时应该应用的一些API计划实践。凡是，这些实践很有效，并确保API可以在模块化情形中正确行使，譬喻OSGi和Java平台模块体系（JPMS）。有些做法是划定性的，有些则是榨取性的。虽然，其他精采的API计划实践也合用。

OSGi情形行使Java类加载器观念提供模块化运行时逼迫范例可见性（ visibility ）的封装。每个模块都有本身的类加载器，它会被毗连到其他模块的类加载器，以此来共享导出的包并行使导入的包。

Java 9引入了JPMS，它是一个模块化平台，行使了Java说话类型中的 access control 观念来逼迫执行范例的可达性（ accessibility ）的 封装。每个模块界说导出哪些包，因此可由其他模块会见。默认环境下，JMPS层中的模块都驻留在统一个类加载器中。

包可以包括API。API包有两种脚色： API consumers and API providers 。

在以下计划实践中，我们将接头包的民众部门。措施包中非public或非protected的成员和范例，在措施包之外是不行会见的，因此它们是措施包的实现细节。

必需计划Java包以确保它是一个内聚、不变的单位。在模块化Java中，包是模块之间的共享实体。一个模块可以导出包，以便其他模块可以行使该包。因为包是模块之间共享的单位，因此包必需具有内聚性，由于包中的全部范例都必需与包的特定用途相干。像java.util这样的包是不勉励的，由于这种包中的范例凡是互相没有相关。这样的非内聚的包也许导致很多依靠性题目，由于包的不相干部门引用其他不相干的包，而且修改包的一个部门会影响依烂魅这个包的全部模块，纵然模块现实上也许不行使被修改的这部门。

因为包是单位共享，因此其内容必需是众所周知的，而且包括的API仅在兼容方法中跟着包在将来版本的成长而变革。这意味着包不能支持API超集或子集;譬喻，javax.transaction就是一个内容不不变的包。包的用户必需可以或许知道包中哪些范例是可用的。这也意味着包应该由单个实体（譬喻，jar文件）提供，而不是跨多个实体分隔，由于包的用户必需知道整个包的存在。

另外，包必需以一种兼容的方法成长。因此，应该对包举办版本节制，而且其版本号必需按照semantic versioning 法则举办演变。

但最近我意识到包的首要版本变动的语义版本节制提议是错误的。包演变必需是成果的增进。在语义版本节制中，这增进了次要版本。当您删除成果时，即对包举办不兼容的变动，您必需移动到新的包名称，使原始包如故兼容。要相识为什么这很重要且须要，请参阅本文 Semantic Import Versioning for Go 。这两种环境都合用于在对包举办不兼容的变动时转移到新包名而不是变动首要版本的环境。

包中的范例可以引用其他包中的范例。譬喻，要领的参数范例和返回范例以及字段的范例都也许引用其他包的范例。这种包间耦合缔造了所谓的包与包之间的 uses相关 。这意味着API consumer必需行使与API provider沟通的引用包，以便他们领略引用的范例。

凡是，，我们但愿最小化包间耦合以最小化对包的行使束缚。这简化了OSGi情形中的布线判别率，并最大限度地镌汰了依靠扇出，简化了陈设（This simplifies wiring resolution in the OSGi environment and minimizes dependency fan-out simplifying deployment）。

对付API，接口比类更受接待。这是一种相等常见的API计划实践，对模块化Java也很重要。对接口的实现很自由，一个接口可以有多个实现。接口对付将API consumer与API provider疏散是很重要的。它使得一个包括API的包，既可以被API consumer行使，也可以被API provider行使。通过这种方法，API consumer与API provider没有直接的依靠相关。它们都只依靠于API包。

抽象类偶然是一种有用的计划选择，但凡是接口是首选，出格是思量到最近接口添加了default  methods这一改造.

最后，API凡是必要很多小的详细类，譬喻变乱范例和非常范例。这很好，但范例凡是应该是不行变的，不得当API行使者举办子类化。

应该在API中停止行使静态。范例不该该有静态成员。应停止行使静态工场。应该将实例建设与API疏散。譬喻，API consumer应该通过依靠注入或工具注册表（如OSGi处事注册表可能JPMS的java.util.ServiceLoader）来吸取API范例的工具实例.

停止静态也是建造可测试API的好要领，由于静态不轻易被模仿。

偶然在API计划中有单例工具。可是，对单例工具的会见不该该像静态一样通过静态getInstance要领或静态字段来会见。当必要单个工具时，该工具应该由API界说为单例，并通过依靠注入或如上所述的工具注册表提供应API consumer。

API凡是具有可扩展性机制，API consumer可以提供API provider必需加载的类的名称。API provider然后必需行使Class.forName（也许行使的是线程上下文类加载器）来加载类。这种机制担保了从API provider（或线程上下文类加载器）到API consumer的类可见性。 API计划必需停止类加载器假设。模块化的一个要点是范例封装。一个模块（譬喻，API provider）必需不具有对另一个模块（譬喻，API consumer）的实现细节的可见性/可会见性。

API计划必需停止在API consumer和API provider之间转达类名，而且必需停止关于类加载器条理布局和范例可见性/可会见性的假设。为了提供可扩展性模子，API计划应该让API consumer将类工具或更好的实例工具转达给API provider。这可以通过API中的要领或通过工具注册表（譬喻OSGi处事注册表）来完成。见 whiteboard pattern .

java.util.ServiceLoader类，当在JPMS模块中没有行使时，也会受到类加载器假设的影响，由于它假定全部提供者都可以从线程上下文类加载器或提供的类加载器中看到。固然JPMS应承模块声明声明模块提供或行使ServiceLoader managed service，但在模块化情形中凡是不会呈现这种假设 .

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!