Java 是否可能（建议）有一个与实际实现分离的纯api项目？

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

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

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

---

有人把它付诸实践了吗？进展如何？一般来说，您对它有什么看法？

UML让我们以这种方式建模，一些UML工具将根据模型生成代码，这在理论上有助于弥合UML与代码之间的鸿沟

---

企业架构师就是这样一种工具。但这需要您的团队精通UML，也需要精通某些UML工具。

我认为这是一种很好的方法，并一直使用它。我没有经历过这样做的真正缺点

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

我会有一个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

对于我的每个实现。例如：

package my.datasource.urlfetch;

public class UrlFetchDataSource implements DataSource {
    ...
}

---

将接口（契约）和实现分离是合理的设计。但和所有事情一样，适度使用。您不希望将设计限制和复杂化到成本高于交付的程度。记住，它应该是为了增加收益（或降低风险），但它本身并不是一个目标。问问自己为什么要做这些事情，成本和收益是什么，不这样做的相关风险和/或成本是什么。

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

• 优势
  • API和实现的清晰分离
• 缺点
  • 更难理解，因为没有真正的上下文、示例、单元测试来理解API
  • 更难重构，更难理解API定义和更改的后果。我很难想象什么可能是一个好的API，直到我使用了它（并且看到它不能很好地工作）
  • 如果您的API后面有一个（正在运行的）实现是人们无法访问的，那么为真正的应用程序实现真正的测试是困难的，甚至是不可能的

因此，我认为只将API发布为API是很好的，但是在没有真正的源代码的情况下开发API是很困难的，有时在没有运行显示其工作原理的代码的情况下针对真正的API实现API也是很困难的

不同的方法可以是：

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