设计原则之接口隔离原则

最新推荐文章于 2024-03-13 11:00:59 发布
最新推荐文章于 2024-03-13 11:00:59 发布
阅读量190 收藏
点赞数
分类专栏： 设计模式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiaos76/article/details/105472043
版权

接口隔离原则 Interface Segregation Principle , ISP

接口隔离原则定义
客户端不应该被迫依赖它不需要的接口。其中的“客户端”可以理解为接口的调用者或者使用者。

如何理解接口隔离原则
理解接口隔离原则的关键，就是理解其中的“接口”二字。在接口隔离原则中，“接口”可以理解为下面三种情况：

  • 一组API接口集合
    当把接口隔离原则的接口理解成一组API接口集合时，可以是某个微服务的接口，也可以是一些类库的接口等，在设计微服务或者类库接口时，如果部分接口只被部分调用者使用，那只需要单独把需要的接口隔离出来，单独提供给需要的调用者，而不是强迫其他调用者也依赖这部分不会被用到的接口。比如用户微服务系统需要给一些其他系统提供注册、登录、获取用户信息等接口，还需要给一些系统需要删除用户的接口。

    如果我们把所有的接口都放在一起对外提供，那就会存在安全隐患，因为删除操作是一个需要很慎重的操作，应该只限于给有权限的系统调用，如果放在一个接口暴露给所有系统，那就有可能导致一些系统误删用户。所以要么给调用者做接口鉴权，要么通过代码控制，参照接口隔离原则，将删除接口隔离出来，只提供给需要的微服务系统。

public interface UserService{
   boolean register(User user);
   boolean login(User user);
   User getUserInfoById(long id);
   boolean deleteUserById(long id);
}
public class UserServiceImpl implements UserService{
  //...
}

//**************************修改后***********************************
public interface UserService{
   boolean register(User user);
   boolean login(User user);
   User getUserInfoById(long id);
}
public interface RestrictedUserService{
   boolean deleteUserById(long id);
}
public class UserServiceImpl implements UserService, RestrictedUserService{
  //...
}
  • 单个API接口或函数
    当把接口理解为单个API接口或函数时，接口隔离原则说的就是接口函数的设计要功能单一，不要将多个不同的功能逻辑放在一个函数中实现，比如一个系统需要对外提供数据统计接口，如果调用者系统需要的统计数据不一致，有的系统需要max、min、average的统计信息，有的系统只需要average信息，有的只需要sum统计信息，而我们将所有的统计信息都放在一个函数里，等于就是每个调用者系统调用统计信息是，都要将所有的统计数据计算一遍，如果在数据量比较大的时候，就会做很多无用功，影响代码的性能。这里我们就应该将统计函数拆分成细粒度的统计函数，然后调用者系统根据需要调用。
public class statistics{
	private long max;
	private long min;
	private long average;
	private long sum;
	private long percentile99;
	private long percentile999;
}
public Statistics count(Collection<Long> dataSet){
	//...
}

//**************************修改后***********************************
public Long max(Collection<Long> dataSet){ // ... }
public Long min(Collection<Long> dataSet){ // ... }
public Long average(Collection<Long> dataSet){ // ... }
public Long sum(Collection<Long> dataSet){ // ... }
// ...
  • 面向对象编程中的接口概念
    当把接口隔离原则的”接口“理解为面向对象编程中的接口时，比如java中的interface。那接口隔离原则说的就是接口的设计要尽量单一，不要让接口的实现类和调用者依赖不需要的接口函数。

比如我们有一个系统依赖了Kafka，redis 和MySQL，现在需要对这三个组件的配置项实现热更新和监控功能。如果我们将两个功能像如下代码一样设计在一个接口内：

public interface Config{
	void update(); //热更新接口
	String outputInPlainText();  //配置打印
	Map<String,String> output();
}
public class RedisConfig implements Config{
	//接口实现
}
public class KafkaConfig implements Config{
	//接口实现
}
public class MysqlConfig implements Config{
	//接口实现
}
//热更新类
public class SchedulerUpdater{
	//... 省略其他属性和方法...
	private Config config;
	public ScheduleUpdater(Config config,long initialDelayInSeconds,long periodInSeconds){
		//...
	}
	//...
}

//监控类
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){
		// ...
	}
}

以上Config接口包含两类不相关的接口，如果Kafka配置项只需要热更新，不需要监控查看，但由于Config接口包含所有接口，KafkaConfig不得不同时实现所有接口函数，且如果Config接口有任何改动，所有的子类都需要改动，而如果接口的粒度更小，那改动接口函数，涉及改动的子类就相对较少。同时如果有新的监控需求，由于Config的设计，新的功能类不得不实现一些毫无相关的接口函数。

如果我们将Config接口拆开：

// 配置类定义
public class RedisConfig{
	private ConfigSource configSource; // 配置中心(比如zookeeper)
	private String address;
	private int timeout;
	private int maxTotal;
	//省略其他配置
	public RedisConfig(ConfigSource configSource){
		this.configSource = configSource;
	}
	//省略getter setter
	public void update(){
		//从configSource加载配置到address/timeout/maxTotal
	}
}
public class KafkaConfig{ //... }
public class MysqlConfig{ //... }

//热更新
//ScheduleUpdater类以固定时间频率（periodInSeconds）调用需要热更新的
//RedisConfig、KafkaConfig的update()方法更新配置信息。
public interface Updater{
	void update();
}
public class RedisConfig implements Updater{
	//...省略其他属性和方法
	@Override
	public void update(){ // ... }
}
public class KafkaConfig implements Updater{
	//...省略其他属性和方法
	@Override
	public void update(){ // ... }
}
public class MysqlConfig{ // ... }

public class ScheduleUpdater{
	private final ScheduledExecutorService executor = Executors.newSingleThreadScheduledExecutor();
	private long initalDelayInSeconds;
	private long periodInSeconds;
	private Updater updater;
	public ScheduleUpdater(Updater updater, long initalDelayInSeconds,long periodInSeconds){
		this.Updater = updater;
		this.initalDelayInSeconds = initalDelayInSeconds;
		this.periodInSeconds = periodInSeconds;
	}
	public void run(){
		executor.sheduleAtFixedRate(new Runnable(){
			@Override
			public void run(){
				updater.update();
			}
		},this.initalDelayInSeconds,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 KafkaConfig(configSource);
	public static final MysqlConfig mysqlConfig = new MysqlConfig(configSource);
	public static void main(String[] args){
		ScheduleUpdater redisConfigUpdater = new ScheduleUpdater(redisConfig,300,300);
		redisConfigUpdater.run();
		ScheduleUpdater kafkaConfigUpdater = new ScheduleUpdater(kafkaConfig,300,300);
		kafkaConfigUpdater.run();
	}
}

//配置项监控
//在项目中内嵌一个简单的SimpleHttpServer，当访问/config时，在页面显示系统的配置信息。
//这里只有Mysql和Redis需要显示配置信息，Kafka并不想暴露配置信息
public interface Updater{
	void update();
}
public interface Viewer{
	String outputInPlainText();
	Map<String,String> output();
}
public class RedisConfig implements 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 KafkaConfig(configSource);
	public static final MysqlConfig mysqlConfig = new MysqlConfig(configSource);
	public static void main(String[] args){
		ScheduleUpdater redisConfigUpdater = new ScheduleUpdater(redisConfig,300,300);
		redisConfigUpdater.run();
		ScheduleUpdater kafkaConfigUpdater = new ScheduleUpdater(kafkaConfig,60,60);
		kafkaConfigUpdater.run();
		
		SimpleHttpServer simpleHttpServer = new SimpleHttpServer("127.0.0.1",2323);
		simpleHttpServer.addViewer("/config",redisConfig);
		simpleHttpServer.addViewer("/config",mysqlConfig);
		simpleHttpServer.run();
	}
}

以上两个功能单一的接口：Updater和Viewer，隔离了热更新和配置项监控功能，满足接口隔离原则，这种职责单一的接口设计更加灵活，可扩展性好，复用性好。

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

又乖又怂
关注
专栏目录
8.接口隔离原则——面向对象设计原则
李利科
01-29 483
面向对象设计原则除了开闭原则、里氏替换原则、依赖倒置原则和单一职责原则以外，还有接口隔离原则、迪米特法则和合成复用原则。本节将详细介绍接口隔离原则。 接口隔离原则的定义 接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。 2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to dep
七大设计原则之接口隔离原则
学习记录
08-16 718
一、接口隔离原则介绍 客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。初看这个定义，让人摸不着头脑，我们看一个类图，看如下图所示： 类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D。如果接口Interface1对于类A和类C来说不是最小接口，也即类B只需要实现operation1、operatio...
接口隔离原则
学习积累才能前进
05-28 310
定义 使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。 描述 根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种...
IOS设计模式的六大设计原则之接口隔离原则(ISP,Interface Segregation Principle)-附件资源
03-02
IOS设计模式的六大设计原则之接口隔离原则(ISP,Interface Segregation Principle)-附件资源
01.设计原则之接口隔离原则
最新发布
DSDS454651的博客
03-13 1212
单一职责原则针对的是模块、类、接口的设计。接口隔离的原则相对于单一职责原则，一方面更侧重于接口的最小化设计，另一方面更侧重于接口使用的精确性接口隔离原则提供了一种判断接口职责是否单一的标准：通过调用者如何使用接口来间接判定，如果调用者只使用了部分接口或接口的部分功能那么接口设计的就不够职责单一与其他原则一样，你可能会过度使用这条原则。不要进一步划分已经非常具体的接口。记住，创建的接口越多，代码就越复杂。因此要保持平衡。一般来说接口中仅包含某业务模块的方法即可，不应该有其他业务模块的方法。
PHP面向对象五大原则之接口隔离原则(ISP)详解
10-18
面向对象编程中，接口隔离原则（ISP）是五大设计原则之一，它建议不应该强迫客户端依赖于它们不用的接口。在PHP中实现ISP，可以避免不必要的依赖，提高代码的可维护性和灵活性。下面详细说明接口隔离原则的概念、...
软件设计原则之《接口隔离原则》
zhengzhoudaxuexujay的博客
12-25 309
接口隔离原则的定义是：用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。 针对该定义补充如下：     一个类对一个类的依赖应该建立在最小的接口上     建立单一接口，不要建立庞大臃肿的接口     尽量细化接口，接口中的方法尽量少 最后补充一句重要的话：注意适度原则，一定要适度！！！ 为了更好的理解接口隔离原则，接下来写一写代码。 package com....
程序设计原则之接口隔离原则
Wenlong_L的博客
09-16 359
一、什么是接口隔离原则 尽量使用多个专有接口，而不是使用单一的总接口，客户端不应该依赖它不要的接口方法 但是接口数量也不能过多，要适量，否则会增加程序设计的复杂性 二、一个单一总接口的例子 其类图如下： 这样设计就违背了接口隔离的原则，不是所有的鸟都能游泳和飞翔，但是这样实现的Bird类型受限于单一总接口的形式，必须实现这两个方法，哪怕是两个空方法；同样的道理，狗并不能飞...
接口隔离原则有哪三种应用？原则中的“接口”该如何理解？
zhujiangtaotaise的专栏
12-01 280
如何理解“接口隔离原则”？ 接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为 ISP。Robert Martin 在 SOLID 原则中是这样定义它的：“Clients should not be forced to depend upon interfaces that they do not use。”直译成中文的话就是：客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。 实际上，“接口”这个名词可以用在很多场合
设计模式原则(4)--Interface Segregation Principle(ISP)--接口隔离原则
ugug654的博客
08-29 356
作者QQ：1095737364    QQ群：123300273     欢迎加入！ 1.定义: 　　使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。 2.使用场景: 　　类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。即将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们
java设计模式原则——接口隔离原则
u014627852的博客
06-13 361
设计模式回顾： 1.java设计模式 2.java设计模式原则之单一职责原则 接口隔离原则介绍 客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。 举例说明一下： 类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C 来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法。 接口隔离原则处理方法： 将接口 Interface1 拆分为独立的几个接口(这里我们拆
java设计模式-接口隔离原则
兮遥
08-02 171
接口隔离原则(ISP：Interface Segregation Principle) 定义       客户端不应该依赖那些它不需要的接口 另一种定义方法如下:       一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可 ...
接口隔离原则-快速理解
BREATH57的博客
09-02 498
定义 用多个专门的接口，而使用单一的总接口，客户端不应该依赖它不需要的接口 一个类对一个类的依赖应该建立在最小的接口上 建立单一接口，不要建立庞大臃肿的接口 尽量细化接口，接口中的方法尽量少 注意 适度原则，一定要适度！！！否则，导致接口过多，复杂不好管理 优点 符合我们常说的高内聚，低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性 例子 场景： 有一个 interface 具...
设计模式（六）接口隔离原则（DIP）和合成/聚合复用原则（CARP）
weixin_34007886的博客
08-10 295
2019独角兽企业重金招聘Python工程师标准>>> ...
设计模式：接口隔离原则
OceanStar的博客
12-29 326
如何理解接口隔离原则 接口隔离原则。它对应 SOLID 中的英文字母“I”。对于这个原则，最关键就是理解其中“接口”的含义。那针对“接口”，不同的理解方式，对应在原则上也有不同的解读方式。 接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为 ISP。RobertMartin 在 SOLID 原则中是这样定义它的：“Clients should not be forced to depend upon interfaces that they do not
面向对象设计原则：接口隔离
在面向对象设计中，接口隔离原则（Interface Segregation Principle, ISP）是七个核心设计原则之一，对于创建可维护和可复用的软件至关重要。ISP强调的是客户端（即使用接口的类）不应该被迫依赖于它不需要的方法，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值