Question

我被要求使用Maven为即将到来的应用程序创建项目布局。我们将要开发的第一件艺术品将是建筑。为了让开发人员尽可能轻松地工作，我有了将实际实现与API分开的想法（就像在OSGi环境中那样）。

依赖项会将API项目列为编译范围的依赖项，并且实现仅在运行时提供。

通过这种方法，我希望降低开发人员的复杂性，并限制他们使用经常发生变化的内部类。此外，可以隐藏传递依赖关系（例如，我不希望开发人员从前端调用DAO层......这应该只能从服务层看到。）

是否有人将此付诸实践？它是如何实现的？您对此有何看法？

Answer 1

我已经看过很多，这种方法有优点和缺点：

优点
- 明确分离API和实施
缺点
- 更难以理解，因为没有真正的上下文，例如，单元测试来了解API。
- 更难以重构，并了解API定义和更改的后果。我很难想象在使用它之前可能是一个很好的API（并且看到它不能正常工作）。
- 如果您的API背后有一个人们无法访问的（正在运行）实现，则很难甚至不可能为实际应用程序实现真正的测试。

所以我认为将API作为API发布是很好的，但是如果没有真正的源代码就很难开发API，有时候在没有运行显示其工作原理的代码的情况下实现真正的API。

不同的方法可能是：

使用API开发默认实现为showcase。
使用API开发一个示例实现，演示如何使用API。
开发一组单元测试和模拟对象，以展示如何在单元测试中使用API。

Answer 2

分离界面（合同）和实施是合理的设计。但与所有事情一样，请适度使用。您不希望将设计限制和复杂化到成本高于其提供的程度。记住，它应该增加收益（或降低风险），它本身不是目标。问问自己为什么要做这些事情，成本和收益是什么，以及相关的风险和/或不做的成本是什么。

Answer 3

UML让你以这种方式建模，一些UML工具将根据模型生成代码，在理论中，它将有助于弥合从UML到代码的差距，到时候。

Enterprise Architect就是这样一个工具。但是这需要你的团队精通UML以及对某些UML工具的精明。

Answer 4

我认为这是一种很好的方法并且一直使用它。这样做我没有遇到任何真正的缺点。

我的使用示例类似于屏幕抓取库。

我会有一个Maven项目：

data-source-api

有一项服务，如：

package my.datasource.api;

public interface DataSource {
    public GetDataResponse getData(GetDataRequest request);
}

其中GetDataRequest和GetDataResponse（以及其他API类）也在api项目中。

还有Maven项目叫做：

data-source-urlfetch-impl // for appengine
data-source-http-client-impl // for Apache HTTP client
data-source-urlconnection-impl // for appengine/vanilla Java

对于我的每个实现。 E.g：

package my.datasource.urlfetch;

public class UrlFetchDataSource implements DataSource {
    ...
}

是否有可能（推荐）拥有与实际实现分离的纯api项目？

4 个答案: