代码改变世界

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

2018-12-24 20:57 coderidea 阅读(...) 评论(...) 编辑 收藏

本篇介绍企业应用架构的基本模式之一分离接口(Separated Interface)模式。这个模式比较常见,相信我们在应用中已经用过很多次了,甚至在一些架构中成了应用标准,不管用不用得到。

分离接口(Separated Interface)

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

背景

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

做法

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

使用场景

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

  1. 你为通常的情况编写了一些抽象代码,并把这些代码放到了一个框架包中。框架包需要调用一些特定应用的代码。

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

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

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

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

本文首发于个人微信公众号:webguan ;欢迎您的关注