接口隔离原则(Interface Segregation Principle)讲的是:使用多个专门的接口比使用单一的接口总要好。换言之从一个客户类的角度来讲:
一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它不用的方法。
接口隔离原则的定义如下:
客户端不应该依赖那些它不需要的接口。
另一种定义方法如下:
一旦接口太大,则需要将它分割成一些更细小的接口,使用该接口的客户端仅需要知道与之相关的方法即可。
接口隔离原则是指使用多个专门的接口(抽象类也是接口),而不是使用单一的总接口。每个接口应该承担一种相对独立的角色,不多不少,不干不该干的事,该干的事情都要干。
(1)一个接口只代表一个角色,每个角色都有它特定的一个接口,此时这个原则可以叫做"角色隔离原则"。
(2)接口仅仅提供客户端需要的行为,即所需的方法,客户端不需要的行为则隐藏起来,应当为客户提供尽可能小的单独接口,而不是提供大的总结口。
使用接口隔离原则对接口进行约束时,需要注意以下几点:
接口尽量小,但是要有限度。对接口进行细化可以提高程序设计的灵活性是不争的事实,但是如果过小,则会造成接口数量过多,使设计复杂化,所以一定要适度。
为依赖接口的类定制服务,只暴露给调用的类需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小依赖关系。
提高内聚,减少对外交互。使接口用最少的方法完成最多的事情。
运用接口隔离原则,一定要适度(类中的接口数量要适度),接口设计的过大或过小都不好,设计接口的时候,只有多花时间去思考和筹划
才能准确地实践这一原则。
总结:当客户类被强迫依赖那些它们不需要的接口时,则这些客户类不得不受制于这些接口。这无意间就导致了所有客户类之间的耦合。换句话说,如果一个客户类依赖了一个类,这个类包含了客户类不需要的接口,但这些接口是其他客户类所需要的,那么其他客户类要求修改这个类时,这个修改也将影响这个客户类。通常我们都是尽可能的避免这种耦合,所以我们需要竭尽全力地分离这些接口。
接口隔离原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说我们要为各个类建立专门的接口,而不是试图建立一个很庞大的接口供所有依赖他的类去调用。在程序设计中依赖几个专用的接口比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”,通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。
说到这里,很多人觉的接口隔离原则跟之前的单一职责原则很相似其实不然:
其一,单一职责原则注重的是职责,而接口隔离原则注重对接口依赖的隔离。
其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中实现和细节;而接口隔离原则主要约束接口,主要针对抽象,针对程序整体框架的构建。