接口隔离原则_Java设计模式七大设计原则：接口隔离原则

纸上得来终觉浅，绝知此事要躬行。——陆游

※引导语

在设计开发过程中往往会出现这么一现象：在开始设计、开发的时候，一个接口的用来做什么什么的设计的很明确，前期开发过程中接口看着也比较惹人喜爱；随着，开发周期的拉长，尤其是经过几人手后，你会发现，它再也不是那个接口了，而是变得臃肿，都不想看了。

那怎么办呢？

好办，学好咱们今天讲的接口隔离原则，并应用之。

01接口隔离原则是什么

定义

接口隔离原则可以定义为：建立单一接口，不要建立臃肿庞大的接口。

也就是说，接口尽量细化，同时接口中的方法尽量少。

看到这，大家可能会不由自主的想到前面讲的 单一职责原则，“咔”。这里大家一定要注意，单一职责原则，强调的是职责，站在业务逻辑的角度；而接口隔离原则，强调接口的方法尽量少。

02接口隔离原则的好处

符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。

03接口隔离原则规约

在设计接口的时候，我们可以参考以下几点规约：

• 接口要尽量小

这个也是接口隔离原则定义中的核心点，不出现臃肿的接口(Fat Interface)，但是“小”是有限度的，首先就是不能违反单一职责原则，因此，我们在设计接口的时候，也要站在业务角度考虑。

• 接口要高内聚

什么是高内聚？高内聚就是提高接口、类、模块的处理能力，减少对外的交互。具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。

说到高内聚，低耦合必然得提一下。

模块之间存在依赖，关系越紧密， 耦合越强， 模块独立性越差。

模块内部的元素， 关联性越强， 则内聚越高， 模块单一性更强。

因此，好多设计都是基于高内聚低耦合这点考虑的。

• 定制服务

一个系统或系统内的模块之间必然会有耦合，有耦合就要有相互访问的接口(并不一定就是Java中定义的Interface，也可能是一个类或单纯的数据交换)，我们设计时就需要为各个访问者(即客户端)定制服务，什么是定制服务？定制服务就是单独为一个个体提供优良的服务。我们在做系统设计时也需要考虑对系统之间或模块之间的接口采用定制服务。

采用定制服务就必然有一个要求：只提供访问者需要的方法，这是什么意思？

大家可以回想一下自己是怎么做的，如何写这个对外接口的。

我举几个遇到过的例子：

情况1：原来已经有的(可能给后台用的返回所有信息的)接口，直接提供。(不建议，尤其大内容耗时查询)

情况2：有个现成的实现，直接包个接口(Controller)提供出去。(不建议，尤其大内容耗时查询)

情况3：新写一个，按需(所需字段信息)包装接口对外。(建议)

针对于情况1和2，尤其是在并发量大的时候，很容易导致应用服务的性能下降，严重的造成服务宕机。

• 接口设计是有限度的

接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个“度”如何来判断呢？根据经验和常识判断，没有一个固化或可测量的标准。

04代码示例

打电话类图

结合前面讲的UML看此图

           

IConnectionManager：建立连接

IDataTransfer：语音数据转换

Phone：实现电话功能

关注回复 6，获取源代码。

05总结

扫码关注更多精彩 您的点赞、在看和关注，是对小编莫大的支持和鼓励哟！