设计模式（四）：接口隔离原则

什么是接口隔离原则？

定义1：客户端不应该被迫依赖于它没使用的方法。

定义2：类之间的依赖关系应该依赖于尽可能小的接口。

我们要为类建立它们各自需要的接口，不要试图创建一个含有大量接口方法的万能接口给依赖它的类使用。

接口隔离原则的作用？

接口隔离原则为我们提供了一个设计接口的思想，要求我们在设计接口时，要尽量细化接口，接口方法要少，专门提供给依赖该接口的类使用，使该类尽可能少实现它所不使用的接口方法。

如果一个接口的接口方法过多，则系统代码就缺少灵活性，对于外来需求变更的应对性不强，不利于开发与维护。

遵守接口隔离原则具有以下优点：

• 将庞大的接口划分为多个粒度小的接口，降低了系统的耦合性，有利于及时灵活应对外来变更，提高系统的灵活性和可维护性。
• 可以减少代码冗余。庞大的接口里有大量接口方法，若一个类实现这个接口，就必须实现所有的接口方法，很容易造成代码冗余。

为什么要遵守接口隔离原则？

我们将通过简单例子来讲述为何我们要遵守接口隔离原则。我们以简单化程序员日常工作来讲述。

我们定义一个工作接口，里面含有分配任务和编程两个接口方法，开发组长实现这个接口两个方法，程序正常没有问题。老套路我们又要加需求了，这时候我们需要有一个程序员类，它专门负责编程，没有其他工作，这时候我们发现 Work 接口里有 编程 接口方法，于是程序员类直接实现该接口，代码如下：

从功能使用上，这段代码是正常的！但是从工程角度来看，程序员类实现了一个它所不需要的接口方法。假如  开发组长 还需要一个 面试人员 的接口方法，于是我们在 Work 接口里新增 面试人员 的接口方法，DevLead 实现这个方法即可，但是对于 Programmer 再次增加了一个它所不需要的借口，这是不好的现象，造成代码冗余和代码耦合，降低了系统的灵活性和可维护性。

所以我们要把 Work 接口的两个方法隔离开来，如下图所示：

以上把开发组长和程序员角色所需要的接口隔离开来，减少了代码的耦合性和冗余性，对于后来的需求变更也有灵活能力去拓展开发。同时接口设计是有限度的， 我们不可能一个接口里面就放一个接口方法，这是不实际的做法。

设计接口时我们需要结合单一职责原则将相同职责的接口方法放在一起，同时结合项目实际利用接口隔离原则减少接口方法，一般一个接口只服务于一个小功能模块。

接口隔离原则的实现方法

在实际使用接口隔离原则时，我们应该根据以下几个规则来贯彻实行。

• 从业务需求角度分析。每个项目都有自己业务逻辑，开发要求等等因素，导致接口的拆分标准不能一套标准多次复用。所以要具体项目具体去分析怎么拆分能达到较优的效果。
• 接口尽量小，但是要有限度，不能违反单一职责原则。一般一个接口只服务于一个小功能模块。
• 接口要高内聚。在接口中尽量少公布public的方法，使代码内聚有利于降低变更的风险。
• 为依赖接口的类提供定制服务，只提供类所需要的方法,不提供其不需要的方法。

以上就是今天《接口隔离原则》的讲解，良好的代码风格需要长期不断的积累学习。各位读者大人若有问题，欢迎后台留言，我将第一时间回复！

下期文章将介绍《设计模式（五）：最少知识原则》

更多内容欢迎关注我们的微信公众号：IT界的泥石流