接口隔离原则

​

什么是接口隔离原则？

接口隔离原则是一条设计规则：调用方只应依赖自己真正用到的方法，而不应依赖别人碰巧需要的那一包契约。

客户不应被迫依赖他们并不使用的接口。

这不是在求你把类写小。同一个对象仍可以干许多活。这条原则管的是可见性：每个调用方应只看见一张瘦、内聚的脸，哪怕脸后面的对象很大。 日常图像是学校出行表。二十分钟的博物馆参观，不需要过夜医疗同意、银行资料或校车驾照。这些字段若印在同一张纸上，每位家长都得跳过——或填错。法务一改过夜条款，短途表也得重印。厨房改了一道这桌根本没点的菜。 在代码里，一个同时要求 work()、eat()、sleep() 的 “Worker” 类型，对机器人做的是同一件事。空方法、UnsupportedOperationException、以及“别在这里调用”的注释，就是伤。单一职责原则问的是：一个模块是否有太多变更理由。这条原则问的是：某一个调用方是否被出示了太多那些理由。

​

接口隔离原则的三层理解

• 入门：别把打不开的工具箱塞给人。他们只想钉一幅画，开瓶器不是他们的事——直到开瓶器一改，整条工具腰带都得换发。
• 实践：按谁来调用拆接口，而不是按谁来实现。空方法和“不支持”就是气味。胖对象可以同时实现几张瘦脸。
• 进阶：调用方会把变更反向推到自己看见的契约上。胖接口因此把调用方彼此耦合起来。在静态语言里，这是一次重编译。在架构尺度上，仍是马丁后来那句话：依赖一个装了你用不到的东西的模块，是有害的。

​

起源

接口隔离原则起于静态类型面向对象代码里的编译与耦合问题，不是“接口要小”的口号。 罗伯特·C·马丁在 The Interface Segregation Principle（C++ Report 工程笔记专栏的第四篇，1996 年）里把它写下来。上一篇（1996 年 5 月）是依赖倒置原则。这篇专栏的工作定义，就是上面那句引文。马丁针对的是“胖”或“被污染”的接口：一个类的方法可以分成几组，每组服务不同的调用方。有些对象确实需要一张不内聚的表面。他主张：调用方不必把那张表面当成一个类型来认识。 文中第一处伤是一扇能上锁、解锁、报告开关的安全门 Door。TimedDoor 还需要超时报警，于是设计者把 TimerClient 推到 Door 上。不需要计时的门，从此继承一个必须写成空操作的 TimeOut。更糟的是，定时器的一处修正——加上超时编号，免得门关上再打开后误报——会迫使所有 Door 的调用方重编译。马丁的诊断：分开的调用方，就该有分开的接口。父类型上的空实现虚函数，也违反里氏替换原则。 文中更大的例子是 ATM 用户界面。存款、取款、转账各自调用同一个 UI 类型的不同切片。一种交易强加给 UI 的改动，会打到其他所有交易。修法是拆成 DepositUI、WithdrawalUI、TransferUI，再由具体 UI 多重继承。若为了“一处就能拿到全部”又把这些脸包回一个头文件，拆掉的耦合会重新焊上。 马丁在《敏捷软件开发：原则、模式与实践》（Prentice Hall，2003 年）里用配套口号重述：多个面向客户的接口，好过一个通用接口。大约 2004 年，Michael Feathers 把马丁的“前五条”排成 SOLID 口诀。接口隔离原则是其中的 “I”。在《架构整洁之道》（Prentice Hall，2017 年，第 10 章）里，马丁把同一警告扩到类文件之外：依赖一个装了你用不到的东西的模块，是有害的。Martin Fowler 的角色接口从调用方一侧说出同一刀：接口应描述调用方需要的角色，而不是它所交谈的整个对象。 后来的讲授常把最初的咨询洞察放在施乐：一台打印机的 Job 类把打印、装订、传真混在一起。1996 年那篇论文本身并未点名这位客户。公开的展品是计时门和 ATM 界面。

​

核心要点

接口隔离原则在几种调用方共用一个对象、却并不共用同一批方法时，才真正值钱。它不是禁止丰富的对象。它是一条规则：哪些方法，你不许逼一个陌生人去编译。

​

应用场景

当一个对象或表格服务几类受众，且一类受众的改动不应落到其他受众头上时，使用接口隔离原则。不要用它去打碎每个调用方本来就整套使用的内聚工具箱。

​

经典案例

接口隔离原则作为公开 API 的带编号窗口，是 Java 的鼠标事件监听器——不是声称一个 GUI 包等于全部耦合理论。 JDK 1.1（1997 年 2 月 19 日）用委托取代旧的 AWT 继承式事件模型：你实现一个监听器并注册它。鼠标流量是故意切开的。MouseListener 收五个按键与边界方法：mouseClicked、mousePressed、mouseReleased、mouseEntered、mouseExited。MouseMotionListener 收两个运动方法：mouseMoved 和 mouseDragged。O’Reilly 的 Java AWT Reference 用数字说出理由：这一刀让你监听点击，而不被成千上万次运动事件打扰。这一刀是原则在工作。从不跟踪运动的调用方，不依赖运动。 剩下的点击接口仍然胖。多数教程示例只关心五个方法里的一个，其余四个写成空。JDK 自己的答法，同样始于 1.1，是 MouseAdapter：方法体为空的抽象类，你只覆盖关心的事件。Oracle 的 Java SE 文档至今仍这么写。截至 Java SE 26（2026 年），五方法接口和适配器都还在发货。WindowListener 用七个方法和一个 WindowAdapter 重复同一模式。 适配器是便利，不是被隔离的契约。调用方仍对着一个列出自己永不调用的方法的类型来编译。若给 MouseListener 加上第六个鼠标方法，每个直接实现者都得改。Java 8（2014 年 3 月）加入了默认方法，本可以把空实现放到接口上。已公布的监听器类型并未按这个来重做。新设计该抄的是 1997 年那一刀运动/按键切开，而不是适配器补丁：在印出空方法之前，按调用方需要来拆。边界说明：必须同时处理按下、拖动、松开的绘图工具，应把这些方法留在同一张脸上。失效的是把无关受众混在一起的契约，不是每一个方法数大于一的接口。

​

边界与失效场景

当切开比调用方更细时，接口隔离原则失效。若每个调用方总是一起使用 lock、unlock 和 isOpen，三个单方法类型只增加导航，并不去掉耦合。这些方法是一个角色。留在同一张脸上。 它也会在已公布的胖类型上作为补救而失效。MouseListener 就是展品：适配器把空方法盖住，按键事件该切的那一刀从未真下。把 1997 年的适配器称作“模式”，并不使它适合抄进新 API。抄运动/按键那一刀，不要抄五个空桩。 常见误用是每个方法一张接口，然后一堆仍会一起变的类型。那是仪式，不是隔离。另一种误用是把这条原则当成单一职责原则的换名。职责管的是模块为何而变。隔离管的是调用方被迫看见什么。一个模块可以只有一个变更理由，却仍把同一扇胖窗出示给三类无关调用方。出乎意料的空方法也和快速失败作对：程序确实失败了，却失败在胖类型本已广告为平常的一次调用上。

​

常见误区

中文名会撞上“每个接口一个方法”、撞上“只有带 interface 关键字的语言才算”，也撞上把适配器当成切开的替代。

​

相关概念

这些页面挨着同一个问题：如何让几类受众使用同一个对象或表格，而不让每一类受众背上别人的行李。

​

一句话总结