接口隔离原则--设计模式

最新推荐文章于 2024-10-11 16:29:18 发布

Geeks.

最新推荐文章于 2024-10-11 16:29:18 发布

阅读量717

点赞数 22

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

本文链接：https://blog.csdn.net/Darling912/article/details/142020697

版权

设计模式专栏收录该内容

14 篇文章 0 订阅

订阅专栏

1、原理概述
接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为 ISP。Robert
Martin 在 SOLID 原则中是这样定义它的：“Clients should not be forced to
depend upon interfaces that they do not use。”直译成中文的话就是：客户端不
应该强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用
者。
实际上，“接口”这个名词可以用在很多场合中。生活中我们可以用它来指插座接口
等。在软件开发中，我们既可以把它看作一组抽象的约定，也可以具体指系统与系统
之间的 API 接口，还可以特指面向对象编程语言中的接口等。
前面我提到，理解接口隔离原则的关键，就是理解其中的“接口”二字。在这条原则
中，我们可以把“接口”理解为下面三种东西：
一组 API 接口集合
单个 API 接口或函数
OOP 中的接口概念
接下来，我就按照这三种理解方式来详细讲一下，在不同的场景下，这条原则具体是
如何解读和应用的。

接口隔离原则（Interface Segregation Principle，ISP）是一种面向对象编程的设计
原则，它要求我们将大的、臃肿的接口拆分成更小、更专注的接口，以确保类之间的
解耦。这样，客户端只需要依赖它实际使用的接口，而不需要依赖那些无关的接口。
接口隔离原则有以下几个要点：
1. 将一个大的、通用的接口拆分成多个专用的接口。这样可以降低类之间的耦合
度，提高代码的可维护性和可读性。
2. 为每个接口定义一个独立的职责。这样可以确保接口的粒度适当，同时也有助于
遵循单一职责原则。
3. 在定义接口时，要考虑到客户端的实际需求。客户端不应该被迫实现无关的接口
方法。
下面我们来看一个示例，说明如何应用接口隔离原则。
假设我们正在开发一个机器人程序，机器人具有多种功能，如行走、飞行和工作。我
们可以为这些功能创建一个统一的接口：
然而，这个接口并不符合接口隔离原则，因为它将多个功能聚合在了一个接口中。对
于那些只需要实现部分功能的客户端来说，这个接口会导致不必要的依赖。为了遵循
接口隔离原则，我们应该将这个接口拆分成多个更小、更专注的接口：
现在，我们可以根据需要为不同类型的机器人实现不同的接口。例如，对于一个只能
行走和工作的机器人，我们只需要实现 Walkable 和 Workable 接口：
public interface Robot {
void walk();
void fly();
void work();
}
public interface Walkable {
void walk();
}
public interface Flyable {
void fly();
}
public interface Workable {
void work();
}

public interface Robot {
void walk();
void fly();
void work();
}

这就是实现了一个相关的简单的接口

然而，这个接口并不符合接口隔离原则，因为它将多个功能聚合在了一个接口中。对
于那些只需要实现部分功能的客户端来说，这个接口会导致不必要的依赖。为了遵循
接口隔离原则，我们应该将这个接口拆分成多个更小、更专注的接口：

public interface Walkable {
void walk();
}
public interface Flyable {
void fly();
}
public interface Workable {
void work();
}

现在，我们可以根据需要为不同类型的机器人实现不同的接口。例如，对于一个只能
行走和工作的机器人，我们只需要实现 Walkable 和 Workable 接口：

public class WalkingWorkerRobot implements Walkable, Workable {
@Override
public void walk() {
// 实现行走功能
}
@Override
public void work() {
// 实现工作功能
}
}

通过遵循接口隔离原则，我们确保了代码的可维护性和可读性，同时也降低了类之间
的耦合度。在实际项目中，要根据需求和场景来判断何时应用接口隔离原则。
有的同学可以会发出疑问，如果按照上边的例子来说，是不是每个接口只能定义一个
方法了？
一个接口只定义一个方法确实可以满足接口隔离原则，但这并不是一个绝对的标准。
在设计接口时，我们需要权衡接口的粒度和实际需求。过度拆分接口可能导致过多的
单方法接口，这会增加代码的复杂性，降低可读性和可维护性。
关键在于确保接口的职责清晰且单一，以便客户端只需依赖它们真正需要的接口。在
某些情况下，一个接口包含多个方法是合理的，只要这些方法服务于一个单一的职
责。例如，一个数据库操作接口可能包含 connect() 、 disconnect() 、
executeQuery() 等方法，这些方法都是数据库操作的一部分，因此可以放在同一
个接口中。
总之，在遵循接口隔离原则时，我们需要根据实际情况进行权衡，以确保代码既简洁
又易于维护。过度拆分接口并不总是一个好主意，关键是确保接口的职责单一且清
晰。
2、案例解析

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 {
// ... 省略实现代码...
}

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

2）案例二
现在我们再换一种理解方式，把接口理解为单个接口或函数（以下为了方便讲解，我
都简称为“函数”）。那接口隔离原则就可以理解为：函数的设计要功能单一，不要将
多个不同的功能逻辑在一个函数中实现。接下来，我们还是通过一个例子来解释一
下。

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) {

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

如果在项目中，对每个统计需求，Statistics 定义的那几个统计信息都有涉及，那
count() 函数的设计就是合理的。相反，如果每个统计需求只涉及 Statistics 罗列的
统计信息中一部分，比如，有的只需要用到 max、min、average 这三类统计信息，
有的只需要用到 average、sum。而 count() 函数每次都会把所有的统计信息计算一
遍，就会做很多无用功，势必影响代码的性能，特别是在需要统计的数据量很大的时
候。所以，在这个应用场景下，count() 函数的设计就有点不合理了，我们应该按照
第二种设计思路，将其拆分成粒度更细的多个统计函数。
不过，你应该已经发现，接口隔离原则跟单一职责原则有点类似，不过稍微还是有点
区别。单一职责原则针对的是模块、类、接口的设计。而接口隔离原则相对于单一职
责原则，一方面它更侧重于接口的设计，另一方面它的思考的角度不同。它提供了一
种判断接口是否职责单一的标准：通过调用者如何使用接口来间接地判定。如果调用
者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

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 { //... 省略... }

（3）案例三
除了刚讲过的两种理解方式，我们还可以把“接口”理解为 OOP 中的接口概念，比如
Java 中的 interface。我还是通过一个例子来给你解释。
假设我们的项目中用到了三个外部系统：Redis、MySQL、Kafka。每个系统都对应
一系列配置信息，比如地址、端口、访问超时时间等。为了在内存中存储这些配置信
息，供项目中的其他模块来使用，我们分别设计实现了三个 Configuration 类：
RedisConfig、MysqlConfig、KafkaConfig。具体的代码实现如下所示。注意，这里
我只给出了 RedisConfig 的代码实现，另外两个都是类似的，我这里就不贴了。

现在，我们有一个新的功能需求，希望支持 Redis 和 Kafka 配置信息的热更新。所
谓“热更新（hot update）”就是，如果在配置中心中更改了配置信息，我们希望在不
用重启系统的情况下，能将最新的配置信息加载到内存中（也就是 RedisConfig、
KafkaConfig 类中）。但是，因为某些原因，我们并不希望对 MySQL 的配置信息进
行热更新。
为了实现这样一个功能需求，我们设计实现了一个 ScheduledUpdater 类，以固定
时间频率（periodInSeconds）来调用 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() {
刚刚的热更新的需求我们已经搞定了。现在，我们又有了一个新的监控功能需求。通
过命令行来查看 Zookeeper 中的配置信息是比较麻烦的。所以，我们希望能有一种
更加方便的配置信息查看方式。
我们可以在项目中开发一个内嵌的 SimpleHttpServer，输出项目的配置信息到一个
固定的 HTTP 地址，比如：http://127.0.0.1:2389/config 。我们只需要在浏览器中
输入这个地址，就可以显示出系统的配置信息。不过，出于某些原因，我们只想暴露
MySQL 和 Redis 的配置信息，不想暴露 Kafka 的配置信息。
为了实现这样一个功能，我们还需要对上面的代码做进一步改造。改造之后的代码如
下所示：
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();
}
}

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() { //...

至此，热更新和监控的需求我们就都实现了。我们来回顾一下这个例子的设计思想。
我们设计了两个功能非常单一的接口：Updater 和 Viewer。ScheduledUpdater 只
依赖 Updater 这个跟热更新相关的接口，不需要被强迫去依赖不需要的 Viewer 接
口，满足接口隔离原则。同理，SimpleHttpServer 只依赖跟查看信息相关的 Viewer
接口，不依赖不需要的 Updater 接口，也满足接口隔离原则。
你可能会说，如果我们不遵守接口隔离原则，不设计 Updater 和 Viewer 两个小接
口，而是设计一个大而全的 Config 接口，让 RedisConfig、KafkaConfig、
MysqlConfig 都实现这个 Config 接口，并且将原来传递给 ScheduledUpdater 的
Updater 和传递给 SimpleHttpServer 的 Viewer，都替换为 Config，那会有什么问
题呢？我们先来看一下，按照这个思路来实现的代码是什么样的。
}
}
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();
}
}
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() { //... }
}

首先，第一种设计思路更加灵活、易扩展、易复用。因为 Updater、Viewer 职责更
加单一，单一就意味了通用、复用性好。比如，我们现在又有一个新的需求，开发一
个 Metrics 性能统计模块，并且希望将 Metrics 也通过 SimpleHttpServer 显示在网
页上，以方便查看。这个时候，尽管 Metrics 跟 RedisConfig 等没有任何关系，但我
们仍然可以让 Metrics 类实现非常通用的 Viewer 接口，复用 SimpleHttpServer 的
代码实现。具体的代码如下所示：
其次，第二种设计思路在代码实现上做了一些无用功。因为 Config 接口中包含两类
不相关的接口，一类是 update()，一类是 output() 和 outputInPlainText()。理论
上，KafkaConfig 只需要实现 update() 接口，并不需要实现 output() 相关的接口。
同理，MysqlConfig 只需要实现 output() 相关接口，并需要实现 update() 接口。但
第二种设计思路要求 RedisConfig、KafkaConfig、MySqlConfig 必须同时实现
Config 的所有接口函数（update、output、outputInPlainText）。除此之外，如果
我们要往 Config 中继续添加一个新的接口，那所有的实现类都要改动。相反，如果
我们的接口粒度比较小，那涉及改动的类就比较少。
问：
public class ApiMetrics implements Viewer {//...}
public class DbMetrics implements Viewer {//...}
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 final ApiMetrics apiMetrics = new ApiMetrics();
public static final DbMetrics dbMetrics = new DbMetrics();
public static void main(String[] args) {
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();
}
}