接口隔离原则有哪三种应用？原则中的“接口”该如何理解？

最新推荐文章于 2025-08-08 22:01:10 发布

.NET跨平台

最新推荐文章于 2025-08-08 22:01:10 发布

阅读量231

点赞数

CC 4.0 BY-SA版权

分类专栏：架构|领域驱动设计文章标签： java 数据库 memcached

原文链接：https://blog.csdn.net/WuLex

架构|领域驱动设计专栏收录该内容

84 篇文章

订阅专栏

本文详细解析了接口隔离原则（ISP），从三个方面解释了接口的含义：一组API接口集合、单个API接口或函数、OOP中的接口概念。通过示例展示了如何在设计中遵循该原则，确保接口职责单一，避免不必要的依赖。同时，讨论了接口隔离原则与单一职责原则的区别，强调了设计灵活性、扩展性和复用性的关键性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

今天，我们学习SOLID 原则中的第四个原则：接口隔离原则。
对于这个原则，最关键就是理解其中“接口”的含义。那针对“接口”，不同的理解方式，对应在原则上也有不同的解读方式。
此外，接口隔离原则跟我们之前讲到的单一职责原则还有点儿类似，所以，我也会具体讲一下它们间的区别和联系。

如何理解“接口隔离原则”？

接口隔离原则（ISP）

客户端不应该强迫依赖它不需要的接口。
理解“接口”隔离原则的关键，就是理解其中“接口”二字。这条原则中，我们可以把“接口”理解为下面三种东西：
1. 一组 API 接口集合
2. 单个 API 接口或函数

把“接口”理解为一组 API 接口集合

示例：微服务用户系统提供了一组跟用户相关的 API 给其他系统使用。如下

代码


public interface UserService {
  boolean register(String cellphone, String password);
  boolean login(String cellphone, String password);
  UserInfo getUserInfoById(long id);
  UserInfo getUserInfoByCellphone(String cellphone);
}

public class UserServiceImpl implements UserService {
  //...
}

需求
- 添加删除用户功能
分析/设计
- 如果在 UserService 中新添加一个 deleteUserById() 接口。这个方法可以解决问题，但是也隐藏了一些安全隐患。
- 当然，最好的解决方案是从架构设计的层面，通过接口鉴权的方式来限制接口的调用。不过，如果暂时没有鉴权构架来支持，我们还可以从代码设计的层面，尽量避免接口被误用。
- 我们参照接口隔离原则：调用者不应该强迫依赖它不需要的接口。将删除接口单独放到另外一个接口 RestrictedUserService 中，然后将 RestrictedUserService 只打包提供给后台管理系统来使用。

代码


public interface UserService {
  boolean register(String cellphone, String password);
  boolean login(String cellphone, String password);
  UserInfo getUserInfoById(long id);
  UserInfo getUserInfoByCellphone(String cellphone);
}

public interface RestrictedUserService {
  boolean deleteUserByCellphone(String cellphone);
  boolean deleteUserById(long id);
}

public class UserServiceImpl implements UserService, RestrictedUserService {
  // ...省略实现代码...
}

总结
- 我们把接口隔离原则中的接口，理解为一组接口集合，它可以是某个微服务的接口，也可以是某个类库的接口等等。
- 在设计微服务或者类库接口的时候，如果部分接口只被部分调用者使用，那我们就需要将这部分接口隔离出来，单独给对应调用者使用，而不是强迫其他调用者也依赖这部分不会被用到的接口。

把“接口”理解为单个 API 接口或函数

那接口隔离原则就可以理解为：

函数的设计要功能单一，不要将多个不同的功能逻辑在一个函数中实现。

示例：

代码


public class Statistics {
  private Long max;
  private Long min;
  private Long average;
  private Long sum;
  private Long percentile99;
  private Long percentile999;
  //...省略constructor/getter/setter等方法...
}

public Statistics count(Collection<Long> dataSet) {
  Statistics statistics = new Statistics();
  //...省略计算逻辑...
  return statistics;
}

分析：
- count() 函数的功能不够单一，包含很多不同的统计功能。
- 按照接口隔离原则，我们应该把 count() 函数拆成几个更小粒度的函数，每个函数负责一个独立的统计功能。

代码（拆分后）


public Long max(Collection<Long> dataSet) { //... }
public Long min(Collection<Long> dataSet) { //... } 
public Long average(Colletion<Long> dataSet) { //... }
// ...省略其他统计函数...

接口隔离原则跟单一职责原则的区别。
1. 侧重点不同
  - 单一职责原则针对的是模块、类、接口的设计。
  - 接口隔离原则更侧重于接口的设计。
2. 思考角度不同
  - 接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接判定。如果调用者只使用部分接口或接口部分功能，那接口的设计就不够职责单一。

把“接口”理解为 OOP 中的接口概念

示例，

背景：
- 我们项目中用到了三个外部系统：Redis、MySQL、Kafka。每个系统都对应一系列的配置信息。
设计
- 我们分别设计实现了三个 Configuration 类：RedisConfig、MySQLConfig、KafkaConfig。

代码（RedisConfig 如下，其他类似）


public class RedisConfig {
    private ConfigSource configSource; //配置中心（比如zookeeper）
    private String address;
    private int timeout;
    private int maxTotal;
    //省略其他配置: maxWaitMillis,maxIdle,minIdle...

    public RedisConfig(ConfigSource configSource) {
        this.configSource = configSource;
    }

    public String getAddress() {
        return this.address;
    }
    //...省略其他get()、init()方法...

    public void update() {
      //从configSource加载配置到address/timeout/maxTotal...
    }
}

public class KafkaConfig { //...省略... }
public class MysqlConfig { //...省略... }

需求一
- 希望支持 Redis、Kafka 配置信息热更新。不希望对 MySQL 的配置信息进行热更新。
需求设计：
- 设计一个 ScheduledUpdate 类，以固定时间频率来调用 RedisConfig、KafkaConfig 的 update() 方法更新配置信息。

代码


public interface Updater {
  void update();
}

public class RedisConfig implemets Updater {
  //...省略其他属性和方法...
  @Override
  public void update() { //... }
}

public class KafkaConfig implements Updater {
  //...省略其他属性和方法...
  @Override
  public void update() { //... }
}

public class MysqlConfig { //...省略其他属性和方法... }

public class ScheduledUpdater {
    private final ScheduledExecutorService executor = Executors.newSingleThreadScheduledExecutor();;
    private long initialDelayInSeconds;
    private long periodInSeconds;
    private Updater updater;

    public ScheduleUpdater(Updater updater, long initialDelayInSeconds, long periodInSeconds) {
        this.updater = updater;
        this.initialDelayInSeconds = initialDelayInSeconds;
        this.periodInSeconds = periodInSeconds;
    }

    public void run() {
        executor.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                updater.update();
            }
        }, this.initialDelayInSeconds, this.periodInSeconds, TimeUnit.SECONDS);
    }
}

public class Application {
  ConfigSource configSource = new ZookeeperConfigSource(/*省略参数*/);
  public static final RedisConfig redisConfig = new RedisConfig(configSource);
  public static final KafkaConfig kafkaConfig = new KakfaConfig(configSource);
  public static final MySqlConfig mysqlConfig = new MysqlConfig(configSource);

  public static void main(String[] args) {
    ScheduledUpdater redisConfigUpdater = new ScheduledUpdater(redisConfig, 300, 300);
    redisConfigUpdater.run();
    
    ScheduledUpdater kafkaConfigUpdater = new ScheduledUpdater(kafkaConfig, 60, 60);
    redisConfigUpdater.run();
  }
}

需求二
- 希望能有一种更加方便的配置信息查看方式，
设计
- 有项目中，开发一个内嵌的 SimpleHttpServer，输出项目的配置信息到一个固定的 HTTP 地址。
- 只想暴露 MySQL 和 Redis 和配置信息，不想暴露 Kafka 的配置信息。

代码


public interface Updater {
  void update();
}

public interface Viewer {
  String outputInPlainText();
  Map<String, String> output();
}

public class RedisConfig implemets Updater, Viewer {
  //...省略其他属性和方法...
  @Override
  public void update() { //... }
  @Override
  public String outputInPlainText() { //... }
  @Override
  public Map<String, String> output() { //...}
}

public class KafkaConfig implements Updater {
  //...省略其他属性和方法...
  @Override
  public void update() { //... }
}

public class MysqlConfig implements Viewer {
  //...省略其他属性和方法...
  @Override
  public String outputInPlainText() { //... }
  @Override
  public Map<String, String> output() { //...}
}

public class SimpleHttpServer {
  private String host;
  private int port;
  private Map<String, List<Viewer>> viewers = new HashMap<>();
  
  public SimpleHttpServer(String host, int port) {//...}
  
  public void addViewers(String urlDirectory, Viewer viewer) {
    if (!viewers.containsKey(urlDirectory)) {
      viewers.put(urlDirectory, new ArrayList<Viewer>());
    }
    this.viewers.get(urlDirectory).add(viewer);
  }
  
  public void run() { //... }
}

public class Application {
    ConfigSource configSource = new ZookeeperConfigSource();
    public static final RedisConfig redisConfig = new RedisConfig(configSource);
    public static final KafkaConfig kafkaConfig = new KakfaConfig(configSource);
    public static final MySqlConfig mysqlConfig = new MySqlConfig(configSource);
    
    public static void main(String[] args) {
        ScheduledUpdater redisConfigUpdater =
            new ScheduledUpdater(redisConfig, 300, 300);
        redisConfigUpdater.run();
        
        ScheduledUpdater kafkaConfigUpdater =
            new ScheduledUpdater(kafkaConfig, 60, 60);
        redisConfigUpdater.run();
        
        SimpleHttpServer simpleHttpServer = new SimpleHttpServer(“127.0.0.1”, 2389);
        simpleHttpServer.addViewer("/config", redisConfig);
        simpleHttpServer.addViewer("/config", mysqlConfig);
        simpleHttpServer.run();
    }
}

分析：
- 我们设计了两个功能非常单一的接口：Update 和 Viewer。
- ScheduledUpdate 只依赖 Update 这个跟热更有关的接口，不需要被强迫依赖不需要的 Viewer 接口，满足接口隔离原则。
- SimpleHttpServer 只依赖跟查看信息相关的 Viewer 接口，不需要 Update 接口，也满足接口隔离原则。

反例：如果我们不遵守接口隔离原则，不设计 Update 和 Viewer 两个小接口。而设计一个大而全的 Config 接口。

代码

public interface Config {
  void update();
  String outputInPlainText();
  Map<String, String> output();
}
public class RedisConfig implements Config {
  //...需要实现Config的三个接口update/outputIn.../output
}
public class KafkaConfig implements Config {
  //...需要实现Config的三个接口update/outputIn.../output
}
public class MysqlConfig implements Config {
  //...需要实现Config的三个接口update/outputIn.../output
}
public class ScheduledUpdater {
  //...省略其他属性和方法..
  private Config config;
  public ScheduleUpdater(Config config, long initialDelayInSeconds, long periodInSeconds) {
      this.config = config;
      //...
  }
  //...
}
public class SimpleHttpServer {
  private String host;
  private int port;
  private Map<String, List<Config>> viewers = new HashMap<>();
  public SimpleHttpServer(String host, int port) {//...}
  public void addViewer(String urlDirectory, Config config) {
    if (!viewers.containsKey(urlDirectory)) {
      viewers.put(urlDirectory, new ArrayList<Config>());
    }
    viewers.get(urlDirectory).add(config);
  }
  public void run() { //... }
}

对比，前后两种设计思路，
1. 第一种设计思路更加灵活、易扩展、易复用。
  - Update、Viewer 职责更加单一，单一就意味着通用、复用性好。
2. 第二种设计思路在代码实现上做了一些无用功。
  - 第二种设计思路要求 RedisConfig、KafkaConfig、MySQLConfig 必须同时实现 Config 所有接口函数。
  - 如果要往 Config 中添加一个新接口，那所有的实现类都要改动。相反，如果接口粒度比较小，那涉及改动的类就比较少。