企业应用架构的基本模式之分离接口

本篇介绍企业应用架构的基本模式之一分离接口（Separated Interface）模式。这个模式比较常见，相信咱们在应用中已经用过不少次了，甚至在一些架构中成了应用标准，无论用不用获得。

分离接口（Separated Interface)

在一个包中定义接口，而在另外一个与这个包分离的包中实现这个接口。

背景

当开发系统时，可经过减小系统部件之间的耦合程度来改进设计质量。减小耦合的一个较好方法是将类分组，而后组成成包，并限制包间的依赖关系。这样就能够对包间的调用加入某些规则。可是，你可能须要调用某些与包之间通常性依赖关系有冲突的方法。在这种状况下，可使用分离接口模式。

作法

在一个包中定义接口，但在另外一个包中实现这个接口。此时与接口有依赖关系的客户没法感知到实现的存在。分离接口为入口提供了一个良好的插入点。

使用场景

当你须要打破系统两个部分之间的依赖关系时，可使用分离接口，如下为一些实际场景：

1. 你为一般的状况编写了一些抽象代码，并把这些代码放到了一个框架包中。框架包须要调用一些特定应用的代码。

2. 一层中某些代码须要调用另外一层的代码，但调用者又不该该知道被调用者的存在，例如在Dubbo或者Hsf定义的服务接口

3. 你须要调用另外一开发组开发的函数，可是又不想与他们所提供的API产生依赖关系。

许多开发者，他们为编写的每个类都使用了分离接口。我的认为有些过犹不及，尤为对于普通应用程序的开发而言。保持接口与实现的分离须要额外的工做。建议只有当你但愿打破依赖关系，或者同一接口有多个独立的实现才使用一个分离接口。若是你把接口和实现放在一块儿，再在未来某一时刻分开它们也不仅过是一个简单的重构，彻底能够将它推迟到你必须如此时再实施。由于某种程序上，这种模式下依赖关系的管理显得有些过于复杂。通常状况下，在建立对象时与实现类创建依赖关系，然后只使用接口就已经够了。但当你想要实施某些依赖规则时就会出现问题，例如要在编译时进行依赖关系的核查。此时全部的依赖关系必须被移除。对于较小的系统，是否实施依赖规则可有可无，但对大型系统，依赖规则的实施倒是极有价值的。

代码示例地址：https://github.com/tianyaxiang/ApplicationArchitecture

本文首发于我的微信公众号：webguan ；欢迎您的关注