【iOS-设计模式】六大设计原则之接口隔离原则(ISP,Interface Segregation Principle)

定义

客户端不应该依赖它不需要的接口;
一个类对另一个类的依赖应该建立在最小的接口上。

定义解读

定义包含三层含义:

  1. 一个类对另一个类的依赖应该建立在最小的接口上;
  2. 一个接口代表一个角色,不应该将不同的角色都交给一个接口,因为这样可能会形成一个臃肿的大接口;
  3. 不应该强迫客户依赖它们从来不用的方法。

接口隔离原则有点像单一职责原则,但是也有区别,在单一职责原则中,一个接口可能有多个方法,提供给多种不同的调用者所调用,但是它们始终完成同一种功能,因此它们符合单一职责原则,却不符合接口隔离原则,因为这个接口存在着多种角色,因此可以拆分成更多的子接口,以供不同的调用者所调用。比如说,项目中我们通常有一个 Web 服务管理的类,接口定义中,我们可能会将所有模块的数据调用方法都在接口中进行定义,因为它们都完成的是同一种功能:和服务器进行数据交互;但是对于具体的业务功能模块来说,其他模块的数据调用方法它们从来不会使用,因此不符合接口隔离原则。

优点

使用接口隔离原则,意在设计一个短而小的接口和类,符合我们常说的高内聚低耦合的设计思想,从而使得类具有很好的可读性、可扩展性和可维护性。

问题提出

类 A 通过接口 I 依赖类 B,类 C 通过接口 I 依赖类 D,如果接口 I 对于类 A 和类 C 来说不是最小接口,而类 B 和类 D 必须去实现它们不需要的方法。下面通过一个 UML 图来说明这种现象:

image.png

在这里,我们定义了一个动物活动的接口 IAnimal,里面有4个方法:飞行 fly、行走 walk、吃 eat 和工作 work,然后分别用人类 People 和鸟类 Bird 实现了这个接口。中国人类 ChinesePeople 和鹦鹉类 Parrot 通过接口 IAnimal 分别依赖类 People 和类 Bird。很明显,对于 ChinesePeople 来说,fly 方法是多余的,因为人不会飞;对于 Parrot 类来说,work 方法是多余的,因为鹦鹉不需要工作。接口 IAnimal 对于类 ChinesePeople 和类 Parrot 来说不是最小接口。

解决方案

将臃肿的接口 IAnimal 拆分为独立的几个接口,类 ChinesePeople 和类 Parrot 分别与它们需要的接口建立依赖关系,也就是采用接口隔离原则。修改后的 UML 图如下所示:

image.png

示例

说明:从 UML 图可以看到,遵守接口隔离原则,会使代码量增加不少,源码中也是这样;实际上,iOS 在定义协议的时候,可以设置方法为可选实现(@optional)和必须实现(@required,默认值),我们可以设置 work 方法和 fly 方法为可选实现的方法,这样在类 People 和类 Bird 中,这两个方法可以根据需要来决定是否实现。采用这种方式,功能上实现是没有问题,对于简单的接口来说,也便于维护和管理。但是,当方法随着业务需求的增加而不断增加的话,如果我们不应用接口隔离原则,那么就可能形成一个庞大臃肿的接口,这样的接口的可维护性和重用性是很差的。因此,我们应该尽量细化接口,本篇将一个接口变更为3个专用的接口所采用的就是接口隔离原则。在项目开发中,依赖几个专用的接口要比依赖一个综合的接口更加灵活。通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。

虽然接口隔离原则很有意义,但在实际项目中,应该注意度的把握,接口设计的过大或过小都不好,应该根据实际情况多思考再进行设计。

你可能感兴趣的:(【iOS-设计模式】六大设计原则之接口隔离原则(ISP,Interface Segregation Principle))