设计模式学习笔记 - 设计原则 - 4.接口隔离原则

陈建111

已于 2024-03-15 12:56:14 修改

阅读量1.1k

点赞数 15

分类专栏：设计模式-实战文章标签：接口隔离原则

于 2024-03-02 00:00:06 首次发布

本文链接：https://blog.csdn.net/chenjian723122704/article/details/136406288

版权

设计模式-实战专栏收录该内容

89 篇文章 0 订阅

订阅专栏

前言

今天学习 SOLID 原则中的字母 “I”，接口隔离原则，Interface Segregation Principle，缩写为 ISP。

英文原文：Clients should not be forced to depend upon interfaces that they do not use。翻译成中文就是：客户端不应该被强迫依赖它不需要的接口。

这个原则，最关键就是理解其中“接口”的含义。我们可以把接口理解为下面三种东西：

一组 API 集合
单个 API 接口或函数
OOP 中接口的概念

在这里插入图片描述

把“接口”理解为一组 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 中增加一个 deleteUserByCellPhone() 或 deleteUserById() 接口就可以了。这个方法可以解决问题，但也隐藏了一些安全隐患。

删除用户是一个非常慎重的操作，我们只希望通过管理后台来执行，所以这个接口只限于管理后台使用。如果把它放到 UserService 中，那所有使用到 UserService 的系统，都可以调用这个接口。不加限制地被其他业务系统调用，就有可能误删用户。

当然，最好的解决方案是从架构设计层面，通过接口鉴权的方式来限制接口的调用。不过，还可以从代码设计的层面，尽量避免接口被误用。我们参照接口隔离原则，调用者不应该强迫依赖它不需要的接口，将删除接口单独放到另外一个接口 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;
    // 省略getter、setter、constructor...
}

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

在上面的代码中，count() 函数的功能不够单一，包含很多不同的统计功能，比如，求最大值、最小值、评价值等等。按照接口隔离原则，我们应该把 count() 函数拆分成几个更小粒度的函数，每个函数负责一个独立的统计功能。拆分之后的代码如下所示：

public Statistics max(Collection<Long> dataSet) { /*...*/ }
public Statistics min(Collection<Long> dataSet) { /*...*/ }
public Statistics average(Collection<Long> dataSet) { /*...*/ }

不过，在某种意义上， count() 函数也不算算是职责不够单一，比较它做的事情只是和统计相关。我们在讲单一职责原则的时候，也提过类似的问题。实际上，判断功能是否单一，除了很强的主观性，还需要结合具体的场景。

例如，对每个统计需求，Statistics 定义的几个统计信息都有涉及，那 count() 的设计就是合理的。
相反，如果每个统计只需要设计 Statistics 中的一部分，比如，有的只需要用到 max、min、average，有的只需要用到 average、sum。而 count() 函数每次都会把所有的统计信息都会计算一遍，就会做很多无用功，势必影响代码的性能，特别是在需要统计的数据量很大的时候。所以在这个场景下， count() 函数的设计就有点不合理了，应该按照第二种设计思路，将其拆分成粒度更细的多个统计函数。

不过你应该已经发现，接口隔离原则和单一职责原则有些类似，不过稍微还是有些区别。

单一职责原则针对的是模块、类、接口的设计。
而接口隔离原则，一方面更加侧重于接口，另一方它的思考角度不同。

它提供了一种判断接口是否职责单一的标准：通过调用者来间接地判定。

如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

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

还可以把“接口”理解为 OOP 中的接口概念，比如 Java 中的 interface。还是通过例子来解释。

假设项目中用到了三个外部系统：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() {
        // 从 configuration 加载配置到 address/timeout/maxTotal...
    }
}

public class MysqlConfig { /*...*/ }
public class KafkaConfig { /*...*/ }

现在有个新需求，希望支持 Redis 和 Kafka 配置信息的热更新。所谓“热更新”就是，如果在配置中心更改了配置信息，我们希望在不用重启系统的情况下，能将最新的信息加载到内存中（也就是 RedisConfig、KafkaConfig 中）。但是，因为某些原因，我们并不希望对 MySQL 的配置信息进行热更新。

为了实现这个一个功能需求，我们设计实现了 ScheduledUpdater 类，以固定的时间频率来调用 RedisConfig、KafkaConfig 的 update() 方法更新配置信息。具体的实现代码如下所示：

public interface Updater {
    void update();
}

public class RedisConfig implements Updater{
    // 省略其他属性和方法...
    @Override
    public void update() {
        // 从 configuration 加载配置到 address/timeout/maxTotal...
    }
}

public class KafkaConfig implements Updater{
    // 省略其他属性和方法...
    @Override
    public void update() {
        // 从 configuration 加载配置到 address/timeout/maxTotal...
    }
}

public class MysqlConfig { /*...*/ }

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

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

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

public class Application {
    static ConfigSource configSource = new ZookeeperConfigSource(/*省略参数*/);
    public static final RedisConfig redisConfig = new RedisConfig(configSource);
    public static final MysqlConfig mysqlConfig = new MysqlConfig(configSource);
    public static final KafkaConfig kafkaConfig = new KafkaConfig(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 地址，比如：http://127.0.0.1:2389/config。不过我们只想暴露 MYSQL 和 Redis 的信息，不想暴露 Kafka 的信息。

我们进一步对上面的代码进行改造。

public interface Updater {
    void update();
}

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

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

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

public class MysqlConfig implements Viewer {
    @Override
    public String outputPlainText() { /*...*/ }
    @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 addViewer(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 ScheduledUpdater { /*...*/ }

public class Application {
    static ConfigSource configSource = new ZookeeperConfigSource(/*省略参数*/);
    public static final RedisConfig redisConfig = new RedisConfig(configSource);
    public static final MysqlConfig mysqlConfig = new MysqlConfig(configSource);
    public static final KafkaConfig kafkaConfig = new KafkaConfig(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();
    }
}

至此，热更新和监控的需求我们就都实现了。我们来回顾以下这个例子的设计思想。

我们设计了两个功能非常单一的类： Updater 和 Viewer 。ScheduledUpdater 只依赖 Updater 这个和热更新相关的接口，不需要被强迫去依赖不需要的 Viewer 接口，满足接口隔离原则。同理，SimpleHttpServer 只依赖和它相关的 Viewer 接口，不依赖不需要的 Updater 接口，也满足接口隔离原则。

你可能会说，如果我们不遵守接口隔离原则，不设计 Updater 和 Viewer 两个小接口，而是设计一个大而全的 Config 接口，让 RedisConfig、MysqlConfig、KafkaConfig 都实现这个 Config 接口，并将 Config 传递给 ScheduledUpdater 和 SimpleHttpServer，那么会有什么问题呢？

我们先来看一下按照这个思路实现的代码。

public interface Config {
    void update();
    String outputPlainText();
    Map<String, String> output();
}

public class RedisConfig implements Config {
    //...需要实现Config的三个接口update/outputPlainText/output ...
}
public class KafkaConfig implements Config{
    //...需要实现Config的三个接口update/outputPlainText/output ...
}
public class MysqlConfig implements Config {
    //...需要实现Config的三个接口update/outputPlainText/output ...
}

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>());
        }
        this.viewers.get(urlDirectory).add(config);
    }

    public void run() { /*...*/ }
}

public class ScheduledUpdater {
    // 省略其他属性和方法...
    private Config config;

    public ScheduledUpdater(Config config, long initialDelayInSeconds, long periodInSeconds) {
        this.config = config;
        // ...
    }

    public void run() { /*...*/ }
}

这样的设计思路也能工作，但是对比前后两个设计思路，在同样的代码量、实现复杂度、同等可读性的情况下，第一种设计思路，明显比第二种好很多。主要原因有两点。

首先，第一种设计思路更加灵活、易扩展、易复用。因为 Updater、Viewer 职责更加单一，单一就意味着通用、复用性好。比如，我们现在又有了一个需求，开发一个 Metrics 性能统计模块，并且希望将 Metrics 也通过 SimpleHttpServer 显示在网页上，以方便查看。这个时候，尽管 Metrics 跟 RedisConfig 等没有任何关系，但我们仍然可以让 Metrics 实现非常通用的 Viewer 接口，复用 SimpleHttpServer 的代码实现，具体的代码如下所示：

public class ApiMetrics implements Viewer { /*...*/ }
public class DbMetrics implements Viewer { /*...*/ }

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

    public static final ApiMetrics apiMetrics = new ApiMetrics();
    public static final DbMetrics dbMetrics = new DbMetrics();

    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.addViewer("/metrics", apiMetrics);
        simpleHttpServer.addViewer("/metrics", dbMetrics);
        simpleHttpServer.run();
    }
}

其次，第二种设计思路在代码上做了一些无用功。因为 Config 接口中包含两类不相关的接口，一类是 update()，一类是 output() 和 outputPlainText()。理论上：

KafkaConfig 只需要实现 update() 即可，并不需要实现 output 相关的接口。
同理 MysqlConfig 只需要实现 output 相关的接口，并不需要实现 update()。

但是第二种设计思路要求 MysqlConfig、KafkaConfig、MysqlConfig 必须同时实现 Config 的所有接口。除此之外，如果我们要在 Config 中添加一个新的接口，那所有的实现类都要改动。相反，如果我们的接口粒度比较小，那涉及改动的类就比较少。

总结

1.如何理解接口隔离原则？

理解接口隔离原则的重点是理解其中的“接口”二字。这里有三种不同的理解。

如果把接口理解为一组接口集合，可以是某个微服务的接口，也可以是某个类库的接口。如果部分接口只被部分调用者使用，我们就需要将这部分接口隔离出来，单独给这部分调用者使用。而不强迫其他调用者也依赖这部分不会被用到的接口。
如果把接口理解为 API 接口或函数，部分调用者只需要函数中的部分功能，那我们就需要把函数拆分成粒度更细的多个函数，让调用者只依赖它需要的那个细粒度函数。
如果把接口理解为 OOP 中的接口，也可理解为面向对象编程语法中接口语法。那接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数。

2.接口隔离原则与单一职责原则的区别

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

陈建111

关注

15
点赞
踩
9

收藏

觉得还不错? 一键收藏
0
评论
设计模式学习笔记 - 设计原则 - 4.接口隔离原则

如何理解接口隔离原则？理解接口隔离原则的重点是理解其中的“接口”二字。这里有三种不同的理解：把接口理解为一组接口集合；把接口理解为API 接口或函数；把接口理解为OOP 中的接口。
复制链接

扫一扫