主页 > 集合 > 互操作性

API设计

在这个简短但重要的部分，您将学习一些简单的准则，这些准则将使您的API与遵循这些准则的所有其他API无缝协作。本质上，这些规则定义了成为集合世界中良好“公民”的要求。

参数

如果您的API包含一个需要集合输入的方法，那么将相关参数类型声明为集合接口类型至关重要。切勿使用实现类型，因为这会破坏基于接口的集合框架的目的，该框架允许在不考虑实现细节的情况下操作集合。

此外，您应始终使用最不具体但合理的类型。例如，如果可以使用集合接口，则不要要求使用列表或集合。这并不意味着您在输入中永远不应该要求列表或集合；如果方法依赖于这些接口的属性，则可以这样做。例如，Java平台提供的许多算法都需要列表作为输入，因为它们依赖于列表有序的事实。然而，一般规则是，在输入中使用的最好类型是最通用的：集合和映射。

返回值

对于返回值，您可以比输入参数更灵活。返回任何实现或扩展集合接口的类型都是可以的。这可以是其中一个接口，也可以是扩展或实现这些接口的特定用途类型。

例如，可以想象一个名为ImageList的图像处理包，该包返回实现List的新类的对象。除了List操作外，ImageList还可以支持任何需要的特定应用操作。例如，它可以提供一个indexImage操作，返回一个包含ImageList中每个图形的缩略图的图像。重要的是要注意，即使API在输出上提供ImageList实例，它也应接受任意Collection（或者也许是List）实例作为输入。

在某种意义上，返回值应该具有与输入参数相反的行为：最好返回最具体的适用集合接口，而不是最通用的。例如，如果你确定你总是返回一个SortedMap，你应该给相关的方法返回类型为SortedMap，而不是Map。构建SortedMap实例比构建普通Map实例更耗时，而且功能更强大。鉴于你的模块已经投入了时间来构建一个SortedMap，将其增强的功能提供给用户是很合理的。此外，用户将能够将返回的对象传递给需要SortedMap的方法，以及接受任何Map的方法。

遗留的API

目前有很多API定义了自己的特定集合类型。虽然这是不幸的，但考虑到Java平台的前两个主要发布版本中没有集合框架，这是生活的事实。假设你拥有其中一个这样的API；以下是你可以采取的措施。

如果可能的话，将你的遗留集合类型改装为实现标准集合接口之一。然后，你返回的所有集合将与其他基于集合的API无缝地进行交互。如果这是不可能的（例如，因为一个或多个现有类型签名与标准集合接口冲突），则定义一个包装你的遗留集合对象的适配器类，使其能够作为标准集合进行操作。（Adapter类是自定义实现的一个例子。）

如果可能的话，使用符合输入指南的新调用来为你的API添加对标准集合接口对象的接受。这样的调用可以与接受遗留集合类型的调用并存。如果这是不可能的，为你的遗留类型提供一个接受标准接口对象并返回包含相同元素（或映射）的遗留集合的构造函数或静态工厂。这两种方法都将允许用户将任意集合传递到你的API中。