c++通过抽象基类模拟接口，接口隔离是设计原则而非语法特性；接口类须仅含public纯虚函数、无数据成员、虚析构函数；拆分依据是调用方是否同时依赖；多继承需规避命名冲突与歧义。
为什么 C++ 没有 interface 关键字却要搞接口隔离
因为 C++ 的抽象靠纯虚函数和抽象基类（class 带 = 0）模拟接口，但直接堆满虚函数会导致实现类被迫重写无用方法，违背“客户只依赖它需要的”原则。接口隔离不是语法功能，是设计约束——你得主动拆、主动命名、主动检查依赖。
怎么定义真正可隔离的接口类
一个接口类必须满足：只含 public 纯虚函数 + 无数据成员 + 析构函数声明为 virtual 且 = 0 或有实现。否则容易引发对象切片、析构未定义、二进制兼容问题。
- ✅ 正确：
struct IReader { virtual ~IReader() = default; virtual int read() = 0; }; - ❌ 危险：
struct IReader { int buffer[1024]; virtual int read() = 0; };（含数据成员 → 强制耦合内存布局） - ❌ 隐患：
struct IReader { virtual int read(); };（没声明虚析构 → 多态 delete 时未定义行为）
如何判断两个接口该不该合并
看调用方是否总是同时持有两者。如果某个模块只用 read()，另一个模块只用 seek()，那就该拆成 IReader 和 ISeekable。强行合并在头文件里加一堆空实现，会污染实现类的职责边界，也增加单元测试覆盖成本。
- 典型信号：实现类中出现
throw std::runtime_error("not implemented")或返回-1表示“本不该调用” - 重构动作：把共用逻辑抽到非虚辅助函数，接口只保留契约性声明
- 注意 ABI：接口类一旦发布，增删函数会破坏二进制兼容，宁可新增接口类也不扩展现有接口
多继承接口时怎么避免菱形歧义
C++ 允许一个类继承多个接口，但若它们有同名函数（哪怕签名不同），调用时可能触发编译错误或意外重载解析。这不是 bug，是语言机制在提醒你：接口契约冲突了。
立即学习“C++免费学习笔记（深入）”；
- 显式限定调用：
obj.IReader::read()或obj.IWritable::write() - 更稳妥做法：用别名规避命名碰撞，比如把
write()改成write_bytes()，让意图更直白 - 警惕隐式转换：两个接口都提供
operator bool()？编译器可能无法决定走哪条路径
= 0，是每次加新函数前，停下来问一句：这个函数，是不是所有当前和未来实现者都不得不支持？如果不是，就该开个新接口。 
