接口隔离原则（isp）要求按职责切分抽象接口，避免类实现无用虚函数，典型违反信号包括抛异常/返哑值、功能不相关、空测试实现、头文件依赖爆炸；c++中应以小粒度struct纯虚接口组合能力，注意二进制兼容与析构安全。
接口隔离原则（ISP）在 C++ 中不是语法特性，而是一种设计约束：它要求你主动把 class 或 struct 声明的抽象接口按职责切分，避免让一个类被迫实现一堆用不到的虚函数。这直接解决“继承即耦合”的痛点——尤其是多继承场景下，臃肿基类会让子类背上沉重的实现包袱。
怎么识别一个接口已经违反 ISP？
典型信号是出现以下任意一种情况：
- 某个派生类重写基类虚函数时，不得不抛出
std::runtime_error或返回哑值（如return nullptr;）来应付未实现的方法 - 基类中存在明显不相关的功能组合，比如
NetworkService同时包含connect()、renderUI()、logError() - 单元测试中，为覆盖所有纯虚函数而写大量空实现或 mock stub
- 头文件依赖爆炸：一个仅需发送 HTTP 请求的模块，却因继承了含数据库操作的基类，被迫引入
sqlite3.h和openssl/ssl.h
C++ 中拆分接口的实操要点
用 struct 定义纯虚接口是主流做法（C++11 起推荐），关键不在语法，而在粒度控制：
- 每个接口只暴露 1–3 个语义紧密的方法，例如
Readable只含read()和available()，不掺杂seek() - 避免“万能接口”命名，如
IEntity或IService；改用动词导向命名：Serializable、Cancelable、Retryable - 用多重继承组合能力，而非单继承堆砌功能：
class HttpDownloader : public Readable, public Cancelable, public Retryable - 注意虚析构函数必须存在，但只在最顶层接口加一次；子接口无需重复声明
virtual ~Readable() = default;
容易被忽略的兼容性陷阱
拆分后若不谨慎，会破坏二进制兼容性或引发 ODR 违规：
- 不要在已发布的接口中增删虚函数——哪怕只是加个默认参数，也会改变 vtable 布局；新增行为应定义新接口
- 避免跨模块共享同一接口定义：不同动态库若各自定义了同名
Loggable接口，即使签名一致，链接器也可能视为不同类型 - 模板接口（如
template<typename t> struct Processor</typename>）不适用于 ISP 场景，因为其实例化后不再是抽象契约，而是具体实现 - 当用
std::unique_ptr<ireadable></ireadable>传参时，确保所有实现类的析构路径都经过IReadable::~IReadable()，否则资源泄漏
真正难的从来不是“能不能拆”，而是判断“该在哪拆”。一个物理引擎模块对外暴露 PhysicsWorld 接口，里面混着刚体更新、碰撞回调、调试绘制——这时候拆成 Simulatable、Collidable、DebugDrawable 是合理的；但如果为了“绝对最小”而拆出 StepOneFrame、StepHalfFrame，就违背了 ISP 的初衷：接口要服务于客户端的真实使用意图，而不是机械地减少方法数量。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
