OSGI API 包中的具体类答案

【问题标题】：Concrete classes in OSGI API bundleOSGI API 包中的具体类
【发布时间】：2014-04-20 20:15:36
【问题描述】：

我正在构建一个用于清理物理地址的服务。我有一个 API 包，其中包含一个带有清理方法的接口。此方法将采用原始地址数据列表。然后，我将有一个实现包来实现 cleanse 方法并公开服务。然后，客户端包将依赖于 API 包并引用公开的服务。我正在努力找出“最好”的方法来做到这一点。我正在考虑两种选择：

选项 1：
API 包有一个 RawAddress 值类。这意味着我在 API 包中有一个具体的类，我认为这在 OSGI 世界中是不受欢迎的，或者至少不是最佳实践（参见 Is separate OSGI bundles for api and implementation common practice? - 特别是 Neil 对已接受答案的评论）。

从客户的角度来看：

List<RawAddress> rawAddresses = new ArrayList<>();
for(...) {
    RawAddress address = new RawAddress(addrLine, city, state, zip);
    rawAddresses.add(address);
}
List<CleanAddress> cleanAddresses = addressService.cleanse(rawAddresses);

选项 2：
RawAddress 是 API 包中的一个接口。 AddressService 对象将具有用于创建实现 RawAddress 的对象的附加方法。这使得 API 包“纯粹”，但也感觉它可能有点矫枉过正。

从客户的角度来看：

List<RawAddress> rawAddresses = new ArrayList<>();
for(...) {
    RawAddress address = addressService.newRawAddress(addrLine, city, state, zip);
    rawAddresses.add(address);
}
List<CleanAddress> cleanAddresses = addressService.cleanse(rawAddresses);

我觉得我在想这个和/或我错过了一些更好的解决方案。有什么想法吗？

【问题讨论】：

标签： java osgi

【解决方案1】：

我会说这实际上取决于您的 RawAddress 和 CleanAddress 类中存在的确切功能。如果这些只是 POJO，只有私有成员的 setter/getter 并用作 API 功能的参数，我认为将它们包含在 API 包中没有问题。 API 包应仅包含接口的指示在很大程度上与 API 的实际功能（具有随时间变化或可以以不同方式实现的趋势）相关，而与该 API 的参数无关。

就个人而言，我只使用 API 中的接口，即使是参数，但如果 API 方法中使用的参数是 POJO，则在 API 包中提供一个简单的实现。

希望这会有所帮助。

【讨论】：

谢谢，这有助于消除我的困惑。正如您所推测的那样，RawAddress 类确实只是一个没有有趣行为的 POJO。我同意您在 API 中提供默认实现的建议。我对这种妥协感到满意。

【解决方案2】：

两者都可以。这取决于具体类的实现有多大。如果它很简单并且基本上是一个带有构造函数和 getter 的数据持有者，这样您的服务的任何可能实现都将使用具体类，那么将具体类放在 API 包中就可以了。但是，如果具体类很复杂，并且不同的实现可能希望以不同的方式实现它以提供一些附加值，那么只使用 API 包中的接口将是更好的选择。

【讨论】：