本篇介绍企业应用架构的基本模式之一分离接口（Separated Interface）模式。这个模式比较常见，相信我们在应用中已经用过很多次了，甚至在一些架构中成了应用标准，不管用不用得到。
分离接口（Separated Interface)
在一个包中定义接口，而在另一个与这个包分离的包中实现这个接口。
背景
当开发系统时，可通过减少系统部件之间的耦合程度来改进设计质量。减少耦合的一个较好方法是将类分组，然后组成成包，并限制包间的依赖关系。这样就可以对包间的调用加入某些规则。但是，你可能需要调用某些与包之间一般性依赖关系有冲突的方法。在这种情况下，可以使用分离接口模式。
做法
在一个包中定义接口，但在另一个包中实现这个接口。此时与接口有依赖关系的客户无法感知到实现的存在。分离接口为入口提供了一个良好的插入点。
使用场景
当你需要打破系统两个部分之间的依赖关系时，可以使用分离接口，以下为一些实际场景：
- 你为通常的情况编写了一些抽象代码，并把这些代码放到了一个框架包中。框架包需要调用一些特定应用的代码。
- 一层中某些代码需要调用另一层的代码，但调用者又不应该知道被调用者的存在，例如在Dubbo或者Hsf定义的服务接口
- 你需要调用另一开发组开发的函数，但是又不想与他们所提供的API产生依赖关系。
许多开发者，他们为编写的每一个类都使用了分离接口。个人认为有些过犹不及，尤其对于普通应用程序的开发而言。保持接口与实现的分离需要额外的工作。建议只有当你希望打破依赖关系，或者同一接口有多个独立的实现才使用一个分离接口。如果你把接口和实现放在一起，再在将来某一时刻分开它们也不只过是一个简单的重构，完全可以将它推迟到你必须如此时再实施。因为某种程序上，这种模式下依赖关系的管理显得有些过于复杂。一般情况下，在创建对象时与实现类建立依赖关系，而后只使用接口就已经够了。但当你想要实施某些依赖规则时就会出现问题，例如要在编译时进行依赖关系的核查。此时所有的依赖关系必须被移除。对于较小的系统，是否实施依赖规则无关紧要，但对大型系统，依赖规则的实施却是极有价值的。
