面向对象编程原则(07)——接口隔离原则

---

版权声明

• 本文原创作者：谷哥的小弟
• 作者博客地址：http://blog.csdn.net/lfdfhl

---

参考资料

1. 《大话设计模式》 作者：程杰
2. 《Java设计模式》 作者：刘伟
3. 《图解设计模式》 作者：结城浩
4. 《重学Java设计模式》 作者：付政委
5. 《Head First设计模式》作者：埃里克·弗里曼

---

接口隔离原则概述

接口隔离原则，即Interface Segregation Principle；简称为ISP。

该原则定义如下：

客户端不应该依赖那些它不需要的接口。

Clients should not be forced to depend upon interfaces that they do not use

根据接口隔离原则，一个接口太大时需要将它分割成一些更细小的接口；使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担相对独立的角色，只干该干的事。这里的"接口"往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接
口”，它有严格的定义和结构比如Java中的interface。对于这两种不同的含义，ISP的表达方式以及含义也有所不同。

当把“接口”理解成一个类型所提供的所有方法特征的集合的时候，这就是一种逻辑上的概念，接口的划分将直接带来类型的划分。可以把接口理解成角色，一个接口只能代表一个角色，每个角色都有它特定的一个接口，此时这个原则可以叫“角色隔离原则”。

当把“接口”理解成狭义的特定语言的接口，那么ISP表达的意思是指接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。在面向对象编程语言中，实现一个接口需要实现该接口中定义的所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并都承担某一单一角色。接口应该尽量细化，同时接口中的方法应该尽量少，每个接口中只包含一个客户端(如子模块或业务逻辑类)所需的方法即可，这种机制也称为“定制服务”，即为不同的客户端提供宽窄不同的接口。

以下，总结接口隔离原则的核心思想：

• 1、使用多个小的专门的接口，而不要使用一个大的总接口。
• 2、接口应该是内聚的，应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方法，这是一种接口污染。
• 3、接口隔离原则强调接口的单一性。而胖接口存在明显的弊端，会导致实现的类型必须完全实现接口的所有方法等；而某些时候，实现类型并非需要所有的接口定义，在设计上这是“浪费”，而且在实施上这会带来潜在的问题，对胖接口的修改将导致一连串的客户端程序需要修改，有时候这是一种灾难。

接口隔离原则案例

守护神牌安全门具有防火、防盗、防水三种功能，SafeDoor接口设计如下：

public interface SafeDoor {
    //防盗
    void antiTheft();
    //防火
    void fireProof();
    //防水
    void waterProof();
}
1
2
3
4
5
6
7
8

A系列安全门实现该接口并重写接口中的方法，代码如下：

public class SafeDoorA implements SafeDoor {
    public void antiTheft() {
        System.out.println("防盗");
    }

    public void fireProof() {
        System.out.println("防火");
    }

    public void waterProof() {
        System.out.println("防水");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

但是，B系列安全门只有防水、防火功能；此时，再让其实现SafeDoor就有些浪费和多余了。毕竟，B系列安全门根本不需要防盗功能却又不得不重写该方法。显然，这里违背了接口隔离原则。

在此，我们可将原SafeDoor接口拆分成三个小接口，分别封装防水、防火、防盗功能。实现类中可以根据功能的不同选择实现任意一个或多个接口。