接口隔离原则，到底什么需要隔离？-51CTO.COM

通过前面的文章，SRP限制一个类的变化来源应该是单一的；OCP要求不要随意修改一个类；LSP则规范了类的继承关系。那么接口隔离原则会给我们带来什么惊喜呢？今天我们就来聊一聊。

什么是接口隔离？

接口隔离原则，Interface segregation principle（ISP），也是 Robert C. Martin提出的 SOLID原则中的一种，老规矩，还是先看看作者 Robert C. Martin 对接口隔离原则是如何定义的：

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

在作者对接口隔离原则的定义中强调：不应强迫客户依赖他们不使用的接口。

在 Java中，我们一直都强调要面向接口编程，足以看出接口在 Java中的重要性。其实，与单一职责原则类似，接口隔离原则的目标是通过将软件拆分为多个独立的部分来减少所需更改的副作用和频率。

这里的"不应强迫"该如何理解？通常来讲"不应强迫" 有2种理解：

第一种理解是用户不能被强迫使用整个接口。
第二种理解是用户只使用接口中的部分方法，其余的方法不能被强迫使用。

显然，第二种理解比较合理，所以接口隔离原则可以更直白一点的表达成：在接口中，不要放置接口使用者不需要的方法。

站在接口使用者的角度，这样的设计更加人性化，为什么要增加一些我不需要的依赖负担呢？

如何实现接口隔离？

假如有一个业务场景，需要定义一个交通工具的 Transportation类，类中包含设置基本信息（价格，颜色），启停以及飞行等方法：

public interface Transportation{
    void setPrice(double price);
    void setColor(String color);
    void start();
    void stop();
    void fly();
}

汽车属于一种交通工具，因此我们可以定义一个 Car类去实现 Transportation类，代码如下：

public class Car implements Transportation {
    @Override
    public void setPrice(double price) {
       // 价格设置逻辑
    }
    @Override
    public void setColor(String color) {
        // 颜色设置逻辑
    }
    @Override
    public void start(){
        // 启动逻辑
    }
    @Override
    public void stop(){
        // 停止逻辑
    }
    @Override
    public void fly(){
        // 飞行逻辑
    }
}

从上面的代码可以发现一个问题：Car不能飞行却要实现 fly()方法，为什么？显然 fly()这个方法是 Car这种交通工具不需要关注的，这就违反了接口隔离原则。

如何解决这个问题呢？

首先，我们将交通工具接口分成多个角色接口，每个角色接口用于特定的行为，在这里我们可以将 Transportation分成 BasicFeature、 Movable、Flyable 三类行为接口。

// 基本属性， 价格，颜色
public interface BasicFeature{
    void setPrice(double price);
    void setColor(String color);
}

// Movable 行为， 行驶和停止
public interface Movable {
    void start();
    void stop();
}

// 飞行 行为
public interface Flyable {
    void fly();
}

而 Car只需要关注基本属性和 Movable行为，代码如下：

public class Car implements BasicFeature, Movable {
    @Override
    public void setPrice(double price) {
        // 价格设置逻辑
    }
    @Override
    public void setColor(String color) {
        // 颜色设置逻辑
    }
    @Override
    public void start(){
        // 启动逻辑
    }
    @Override
    public void stop(){
        // 停止逻辑
    }
}

Airplane飞机需要关注基本属性，Movable行为和飞行行为，代码如下：

public class Airplane implements BasicCFeature, Movable, Flyable {
    @Override
    public void setPrice(double price) {
        // 价格设置逻辑
    }
    @Override
    public void setColor(String color) {
        // 颜色设置逻辑
    }
    @Override
    public void start(){
        // 启动逻辑
    }
    @Override
    public void stop(){
        // 停止逻辑
    }
    @Override
    public void fly(){
        // 飞行逻辑
    }
}

通过上面的拆解，我们可以看到每种交通工具只需要关注自己需要的接口就好了，自己不需要的接口就不会被强迫关注，更加不会造成 Car能 fly()这样不常见的误区。

接口隔离和单一职责的比较

接口隔离原则和单一职责原则都是 SOLID设计原则中的重要组成部分，虽然它们有一些相似之处，但它们关注的重点和应用的范围有所不同，在实际开发中，很容易搞混淆，因此，这里对这两个原则做详细比较。

关注点不同单一职责原则（SRP）：关注类的职责划分，确保每个类只有为一类行为负责，它主要解决的是类内部职责过多导致的复杂性问题。接口隔离原则（ISP）：关注接口的设计，确保客户端只依赖于它们实际需要的方法。它主要解决的是接口过于庞大导致的依赖问题。
作用范围不同单一职责原则（SRP）：作用于类的设计和实现层面，通过分离职责提高类的内聚性。接口隔离原则（ISP）：作用于接口的设计层面，通过细化接口减少客户端的依赖，提高系统的灵活性。
实现方法不同单一职责原则（SRP）：通过将一个类的多种职责分离成多个独立的类来实现。接口隔离原则（ISP）：通过将一个大接口分解为多个小接口，让不同的客户端依赖于不同的小接口来实现。

因此，接口隔离原则是在遵守单一职责原则的前提下，将接口更加细化。

总结

接口隔离可以提高代码的可读性、可维护性和灵活性，减少系统的耦合度，在实际开发中，合理应用接口隔离原则，可以帮助我们创建高质量的代码和系统。然而，在应用时需要注意适度细化和明确职责，避免过度设计和接口混乱。