接口隔离原则|设计原则

简介: 今天为大家带来的依旧是 设计原则 的知识: 接口隔离原则

前置知识

  • 了解单一职责原则  
  • 熟悉使用面向对象中的接口
  • 有项目开发经历

前言

今天为大家带来的依旧是 设计原则 的知识: 接口隔离原则

首先老规矩,先上百度的定义

定义

一个类对另外一个类的依赖性应当是建立在最小的接口上的。

一个接口代表一个角色,不应当将不同的角色都交给一个接口。没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染。

英文版的解释是这样的

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

结合上下两个定义,我们可以得出。接口隔离原则的意思大致为:服务调用者不该依赖与自己业务无关的接口

这时候我们会发现,这个定义似乎和 单一职责原则 相类似。单一职责所说的是 一个类或者模块只承担一个职责 ,而接口隔离也是强调不依赖与自身无关的东西。这两者确实是十分类似,但是本质上又是不同的。

具体哪里不同,我们先不着急回答,我们先看看接口隔离原则的具体应用和其优势。深入了解之后,我们就能知晓两者的不同了。

如何进行接口隔离?

对于接口的隔离,我们首先要明确我们所描述的接口是什么。

在技术圈,我们有很多种接口,除去物理接口不谈,我们有 SDK、JDK 里面的给我们调用的函数调用接口,有网络的 API接口,有面向对象定义的接口特性,甚至我们说写的函数也可称之为接口。

这么多的接口,事实上都适合于应用 接口隔离原则 ,这些称之为接口的各种特性,他们事实上都可认定为一种协议。而对协议做单一化的规范,就是 接口隔离原则的任务所在。

下面让我们从 面向对象的接口 来举例说明,我们该如何进行接口隔离

假设我们有两个类,学生类和打字员类,学生要实现 homeWork() 方法,打字员要实现 printWork() 方法

public interface PersonWork{
    void homeWork();
    void printWork();
}
public class Student implements PersonWork{
    ...
    @Override
    public void homeWork(){
        ...
    }
    @Override
    public void printWork(){
        //空实现
    }
}
public class PrintPerson implements PersonWork{
    ...
    @Override
    public void homeWork(){
        //空实现
    }
    @Override
    public void printWork(){
        ...
    }
}
复制代码

上述代码中,我们写了一个 PersonWork 接口,包括了两个抽象方法,然后对应的学生类和打字员类都来实现这个接口。

我们发现以上代码有以下的缺点

  1. 不利于接口拓展,修改了一个接口,就得修改多处原本已实现的地方
  2. 实现类继承了无用的方法,导致做无用工
  3. 影响代码可读性,一个大而全的接口类,无法表明清楚接口的特性

所以我们可以进行如下改造,使得符合 接口隔离原则

public interface PersonHomeWork{
    void homeWork();
}
public interface PersonPrintWork{
    void printWork();
}
public class Student implements PersonHomeWork{
    ...
    @Override
    public void homeWork(){
        ...
    }
}
public class PrintPerson implements PersonPrintWork{
    ...
    @Override
    public void printWork(){
        ...
    }
}
复制代码

我们将上述的对应不同功能类的接口独立开,然后需要实现对应功能的类再实现对应的接口。这样子就符合了 接口隔离原则

上述的3个缺点也顺应的解决了。当我们想要拓展的时候,直接定义一个新的接口,进行接口多继承即可。

接口隔离和单一职责的区别

通过上文,想必你已清楚接口隔离所对应的范围与单一职责是不同的。那么我们可以总结出以下的不同点

  1. 应用范围的不同,接口隔离针对的是接口职责是否单一,而单一职责针对的是类或者模块
  2. 判断对象的不同,接口隔离原则判断是否单一的对象是接口调用者,而单一职责原则判断是否单一的对象是较为抽象的业务以及其自身

到此,我们就回答完了前面抛出的问题,也深入理解了该原则


相关文章
|
8月前
|
设计模式 人工智能 Java
软件架构设计原则之依赖倒置原则
依赖倒置原则(Dependence Inversion Principle,DIP)是指设计代码结构时,高层模块不应该依赖低层模块,二者都应该依赖其抽象。抽象不应该依赖细节,细节应该依赖抽象。通过依赖倒置,可以减少类与类之间的耦合性,提高系统的稳定性,提高代码的可读性和可维护性,并且能够降低修改程序所造成的风险。接下来看一个案例,还是以Course(课程)为例,先来创建一个类Tom:
62 0
|
8月前
|
设计模式 关系型数据库 数据安全/隐私保护
软件架构设计原则之单一职责原则
单一职责(Simple Responsibility Pinciple,SRP)是指不要存在多于一个导致类变更的原因。假设我们有一个类负责两个职责,一旦发生需求变更,修改其中一个职责的逻辑代码,有可能导致另一个职责的功能发生故障。这样一来,这个类就存在两个导致类变更的原因。如何解决这个问题呢?将两个职责用两个类来实现,进行解耦。后期需求变更维护互不影响。这样的设计,可以降低类的复杂度,提高类的可读性,提高系统的可维护性,降低变更引起的风险。总体来说,就是一个类、接口或方法只负责一项职责。
66 0
软件架构设计原则之单一职责原则
|
3月前
|
设计模式 存储 NoSQL
【设计模式】软件设计原则-单一职责原则
【1月更文挑战第12天】【设计模式】软件设计原则-单一职责原则
|
3月前
|
设计模式 关系型数据库
【设计模式】软件设置原则-开闭原则
【1月更文挑战第12天】【设计模式】软件设置原则-开闭原则
|
7月前
七大设计原则之接口隔离原则应用
七大设计原则之接口隔离原则应用
21 0
|
8月前
|
设计模式 关系型数据库
软件架构设计原则之接口隔离原则
接口隔离原则符合我们常说的高内聚、低耦合的设计思想,可以使类具有很好的可读性、可扩展性和可维护性。我们在设计接口的时候,要多花时间去思考,要考虑业务模型,包括对以后有可能发生变更的地方还要做一些预判。所以,对于抽象、对于业务模型的理解是非常重要的。下面我们来看一段代码,对一个动物行为进行抽象描述。
58 0
|
8月前
|
设计模式 关系型数据库
软件架构设计原则之里氏替换原则
里氏替换原则(Liskov Substitution Principle,LSP)是指如果对每一个类型为T1的对象o1,都有类型为T2的对象O2,使得以T1定义的所有程序P在所有的对象O1都替换成O2时,程序P的行为没有发生变化,那么类型T2是类型T1的子类型。
55 0
|
8月前
|
设计模式 关系型数据库
软件架构设计原则之迪米特法则
迪米特原则(Law of Demeter LoD)是指一个对象应该对其他对象保持最少的了解,又叫最少知道原则(Least Knowledge Principle,LKP),尽量降低类与类之间的耦合度。迪米特原则主要强调:只和朋友交流,不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称为成员朋友类,而出现在方法体内部的类不属于朋友类。
68 1
|
10月前
|
设计模式 安全 Java
设计原则之接口隔离原则
设计原则之接口隔离原则
48 0
设计原则之接口隔离原则
|
10月前
|
设计模式 安全 Java
设计原则之依赖倒置原则
设计原则之依赖倒置原则
56 0
设计原则之依赖倒置原则