Question

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

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

从客户的角度来看：

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);

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

Answer 1

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

Answer 2

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

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

希望这有所帮助。

OSGI API包中的具体类

2 个答案: