设计模式 ☞ 七大设计原则之接口隔离原则-蒲公英云

设计模式 ☞ 七大设计原则之接口隔离原则

1.1 概述

接口隔离原则(Interface Segregation Principle，ISP)要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。2002 年罗伯特·C·马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法(Clients should not be forced to depend on methods they do not use)。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上(The dependency of one class to another one should depend on the smallest possible interface)。以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
有没有感觉与单一职责原则很像，接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
♞ 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
♞ 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建
简单来说接口隔离原则与单一职责的定义的规则是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，没有要求接口的方法减少，例如一个职责可能包含 10个方法，这 10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束不使用的方法不要访问，按照单一职责原则是允许的，按照接口隔离原则是不允许的。

1.2 优点

① 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
② 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
③ 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
④ 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码
⑤ 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。

1.3 案例

咱们以一个学生管理接口为例，如下图所示，该接口中包含成绩管理、学籍管理、信息管理等众多方法，这样就聚合了太多接口了。StudentInfoImpl 实现类只需要信息管理相关却不得不实现其他不需要使用的方法，很显然这是一个十分蛋疼的接口，设计者应该被拖出去架飞机。

在这里插入图片描述

在开发中我们绝不会像上面去设计一个接口，我们会将其分为几个接口，成绩管理接口负责成绩管理相关方法，信息管理接口负责信息管理相关方法，按需去继承/实现这些接口。以上我们将一个接口拆分为几个接口的行为就体现了接口隔离原则。

在这里插入图片描述

接口设计是有限度的。接口的设计粒度是越小系统越灵活，这是不争的事实，但是这就带来的结构的复杂化，开发难度增加，维护性降低，这不是一个项目或产品所期望看到的，所有接口设计一定要注意适度。接口隔离原则是对接口的定义也同时是对类的定义，接口和都尽量使用原子接口或原子类来组装，但是这个原子该怎么划分是这个模式也是设计中的一大难题，在开发中一般遵循一个接口只服务于一个子模块或者业务逻辑的原则。
接口隔离原则和其他的设计原则一样，都是需要花费较多的时间和精力来进行设计和筹划，但是它带来了设计的灵活性，让你在业务人员在提出“无理”要求的时候可以轻松应付。贯彻使用接口隔离原则最好的方法就是一个接口一个方法，保证绝对符合接口隔离原则，但你会采用吗？！不会，除非你是疯子！那怎么才能正确的使用接口隔离原则呢？答案是根据经验和常识决定接口的粒度大小，接口粒度太小，导致接口数据剧增，开发人员呛死在接口的海洋里；接口粒度太大，灵活性降低，无法提供定制服务，给整体项目带来无法预计的风险。