C++ SOLID 原则（下）：接口隔离与依赖倒置

承接上文，我们将深度解析SOLID原则的最后两个核心支柱——接口隔离原则（ISP） 和依赖倒置原则（DIP）。

如果说SRP（单一职责） 解决的是“类该做多少事”，OCP（开闭原则） 解决的是“如何应对变化”，LSP（里氏替换） 解决的是“继承的底线”，那么：

  • ISP（接口隔离原则） 解决的是“接口该有多胖”，避免“臃肿的契约”污染实现类。
  • DIP（依赖倒置原则） 解决的是“依赖的方向”，它是依赖注入（DI）、工厂模式和插件架构最底层的理论基石。

四、接口隔离原则（ISP）：胖接口之殇与瘦身之道

1. 核心定义

Clients should not be forced to depend on interfaces they do not use.
（客户端不应该被迫依赖它不使用的方法。）

通俗解读：一个接口如果包含了太多方法，就变成了“胖接口”（Fat Interface）。实现类被迫实现一些它根本不需要的方法（比如空实现或抛异常），这违反了单一职责，也破坏了封装性。

2. C++ 反面案例：被迫当“全才”的打印机

想象一个办公设备接口，试图涵盖所有功能：

// ❌ 胖接口（Fat Interface）：包含了所有办公设备的功能
class IMachine {
public:
    virtual ~IMachine() = default;
    virtual void print(const std::string& content) = 0;
    virtual void scan(const std::string& target) = 0;
    virtual void fax(const std::string& number) = 0;
    virtual void staple() = 0;  // 装订
};

// 高端一体机（能实现全部）
class HighEndMachine : public IMachine {
public:
    void print(const std::string& c) override { /* 打印 */ }
    void scan(const std::string& t) override { /* 扫描 */ }
    void fax(const std::string& n) override { /* 传真 */ }
    void staple() override { /* 装订 */ }
};

// 老旧低端打印机（只会打印！但被迫实现所有方法）
class OldPrinter : public IMachine {
public:
    void print(const std::string& c) override { /* 正常打印 */ }
    void scan(const std::string&) override { 
        throw std::runtime_error("Scan not supported!"); // 被迫抛异常！
    }
    void fax(const std::string&) override {
        throw std::runtime_error("Fax not supported!");
    }
    void staple() override {
        throw std::runtime_error("Staple not supported!");
    }
};

// 客户端调用：如果调用方只想要打印，但传入的可能是胖接口
void doPrinting(IMachine& machine) {
    machine.print("Hello");
    // 如果调用方不小心调用了 machine.scan()，老打印机就崩溃了！
}

3. 正确重构：按职责拆分“小而专”的接口（呼应“模块化”）

遵循ISP，我们应该将大接口拆分为多个专注的小接口：

// ✅ 细粒度接口（单一职责）
class IPrinter {
public:
    virtual ~IPrinter() = default;
    virtual void print(const std::string& content) = 0;
};

class IScanner {
public:
    virtual ~IScanner() = default;
    virtual void scan(const std::string& target) = 0;
};

class IFaxMachine {
public:
    virtual ~IFaxMachine() = default;
    virtual void fax(const std::string& number) = 0;
};

class IStapler {
public:
    virtual ~IStapler() = default;
    virtual void staple() = 0;
};

// 老旧打印机：只需实现一个接口！
class OldPrinter : public IPrinter {
public:
    void print(const std::string& c) override { /* 正常打印 */ }
    // 没有 scan()，没有 fax()，干净利落！
};

// 高端一体机：多重继承多个接口（C++的特性在此完美体现）
class HighEndMachine : public IPrinter, public IScanner, public IFaxMachine, public IStapler {
public:
    void print(const std::string& c) override { /* ... */ }
    void scan(const std::string& t) override { /* ... */ }
    void fax(const std::string& n) override { /* ... */ }
    void staple() override { /* ... */ }
};

// 客户端只依赖它真正需要的接口
void doPrinting(IPrinter& printer) { // 只依赖 IPrinter，绝对安全！
    printer.print("Hello");
    // 接口里根本没有 scan()，编译器阻止了错误调用！
}

4. ISP 在扩展技术全景中的体现

相关技术 体现
模块化设计 模块之间的接口依赖必须最小化。Network 模块不应暴露 Database 模块的接口。
策略模式 每个策略接口（如 ICompression）只包含 compress/decompress，不夹杂 encrypt 等无关方法。
依赖注入（DI） 注入的依赖应基于最细粒度的接口。若一个类只需日志功能，就给它注入 ILogger，而非庞大的 IUtility。

五、依赖倒置原则（DIP）：扭转依赖方向，摆脱底层桎梏

1. 核心定义

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
（高层模块不应依赖低层模块，两者都应依赖抽象。抽象不应依赖细节，细节应依赖抽象。）

通俗解读：在传统的自上而下设计中，上层（业务逻辑）会直接依赖下层（数据库、文件系统）。DIP 要求我们将这个依赖倒置：让上层和下层共同依赖一个抽象接口。这样，下层可以被轻松替换（比如从 MySQL 换成 PostgreSQL），而上层代码完全不受影响。

2. C++ 反面案例：业务逻辑直接依赖具体数据库（紧耦合）

// ❌ 低层模块（具体实现）
class MySQLDatabase {
public:
    void connect(const std::string& connStr) { /* MySQL 特定连接 */ }
    void query(const std::string& sql) { /* 执行 MySQL 语法 */ }
};

// ❌ 高层模块（业务逻辑）直接依赖低层具体类
class UserService {
private:
    MySQLDatabase db_;  // 硬编码依赖具体数据库！
public:
    UserService() { db_.connect("mysql://..."); }
    void getUser(int id) {
        db_.query("SELECT * FROM users WHERE id=" + std::to_string(id));
    }
};

// 问题：想切换到 PostgreSQL？必须修改 UserService 源码！（破坏 OCP）

3. 正确重构：引入抽象接口，倒置依赖（呼应“接口”与“DI”）

// ✅ 抽象层（稳定的契约）
class IDatabase {
public:
    virtual ~IDatabase() = default;
    virtual void connect(const std::string& connStr) = 0;
    virtual void query(const std::string& sql) = 0;
};

// ✅ 低层模块（细节）依赖抽象 -> 实现接口
class MySQLDatabase : public IDatabase {
public:
    void connect(const std::string& connStr) override { /* MySQL 实现 */ }
    void query(const std::string& sql) override { /* MySQL 实现 */ }
};

class PostgreSQLDatabase : public IDatabase {
public:
    void connect(const std::string& connStr) override { /* PG 实现 */ }
    void query(const std::string& sql) override { /* PG 实现（语法可能不同） */ }
};

// ✅ 高层模块（业务逻辑）也依赖抽象 -> 通过构造函数注入依赖（呼应 DI）
class UserService {
private:
    std::unique_ptr<IDatabase> db_; // 依赖抽象，而非具体
public:
    // 依赖注入（构造注入）：将依赖从外部传入
    explicit UserService(std::unique_ptr<IDatabase> db) : db_(std::move(db)) {
        db_->connect("...");
    }
    void getUser(int id) {
        db_->query("SELECT * FROM users WHERE id=" + std::to_string(id));
    }
};

// 装配（组合根）：工厂模式创建具体依赖，注入给高层
int main() {
    // 运行时决定注入什么数据库（也可以由配置文件驱动）
    auto db = std::make_unique<PostgreSQLDatabase>();
    UserService service(std::move(db)); // 依赖倒置 + 依赖注入
    service.getUser(123);
    // 若想换 MySQL，只需改一行 new 的对象，UserService 源码毫发无损！
}

4. DIP 在扩展技术全景中的“统治级”地位

相关技术 体现
依赖注入（DI） DIP 是 DI 存在的唯一理由。DI 是 DIP 的具体实现手段（把具体依赖从内部 new 改为外部注入抽象）。
工厂模式 工厂负责创建实现 IDatabase 的具体对象，返回给高层。工厂隔离了“具体类”的变化。
插件机制 宿主程序定义抽象接口（IPlugin），插件实现接口，宿主依赖抽象。插件就是 DIP 中“可替换的低层细节”。
策略模式 Context 依赖 IStrategy（抽象），具体策略实现抽象。完美体现 DIP。

六、SOLID 五原则全景串联图

将这五个原则放在一起看，它们构成了一个完整的设计闭环，缺一不可：

层次 原则 核心思想 解决的根本问题
粒度控制 SRP（单一职责） 一个类一个职责。 防止类变得过大，牵一发而动全身。
交互约束 ISP（接口隔离） 接口要小而专。 防止实现类被迫依赖无用方法（空实现/抛异常）。
层次组织 LSP（里氏替换） 子类必须可替换父类。 确保继承和多态正确，不产生运行时行为崩坏。
扩展策略 OCP（开闭原则） 新增功能靠扩展，不修改旧代码。 让系统在迭代中保持稳定，不引入回归 Bug。
依赖方向 DIP（依赖倒置） 依赖抽象，不依赖具体。 彻底解耦高层与低层，实现“插拔式”架构。

逻辑链条：

先对类做 SRP（职责单一），
再对接口做 ISP（不包含无关方法），
用 LSP 检验继承体系是否安全，
基于前两者，通过抽象接口实现 OCP（扩展新类而不改旧类），
最后用 DIP 控制所有依赖的方向指向抽象，让整个系统像搭积木一样可灵活组装。

七、C++ 工程实战：SOLID 如何共同指导“扩展技术栈”落地

假设我们要构建一个可插拔的日志系统，串联所有原则：

  1. 定义抽象（DIP + ISP）：

    • 定义纯虚接口 ILogger，只包含 log(level, msg) 一个方法（ISP 保证了接口极小）。
    • 所有高层业务类依赖 ILogger（DIP 倒置依赖）。

  2. 具体实现（SRP + LSP）：

    • FileLogger 只负责写文件（SRP）。
    • ConsoleLogger 只负责输出控制台（SRP）。
    • 两者都正确实现了 ILogger，互相可替换（LSP 保障）。

  3. 装配与扩展（OCP + 工厂/DI/插件）：

    • 通过工厂或 DI 容器在运行时创建具体的 Logger。
    • 若新增 RemoteLogger（通过网络发送），只需添加新类实现 ILogger，无需修改任何现有业务代码（OCP 达成）。
    • 若日志格式变了，只改 FileLogger 内部，不影响其他模块（SRP 的功劳）。

八、总结：SOLID 是“道”，设计模式与扩展技术是“术”

封装、继承、多态 是C++语言的“招式”，SOLID原则 是运用这些招式的“心法口诀”，而我们之前学到的工厂、策略、DI、插件、模板则是具体的“战术打法”。

  • 没有 SRP/ISP，工厂造出来的类或接口将极度臃肿，难以维护。
  • 没有 LSP，继承体系下的多态（OCP 的基础）将充满陷阱。
  • 没有 DIP，依赖注入（DI）就成了无源之水，工厂模式也只是换了个地方 new，插件机制更无法实现“热插拔”。

掌握 SOLID 原则，意味着你拥有了评判代码设计好坏的标尺。当你在使用 std::sort（STL）时，你看到的是 OCP（比较器可扩展）；当你写 std::unique_ptr 时，你体会的是 RAII 对资源封装的 SRP；当你设计跨平台模块时，你依赖的是 DIP 和 ISP。

最终建议：在日常编码中，每写完一个类或接口，都问自己一遍 SOLID 五问：

  1. 这个类是否只有一个修改理由？（SRP）
  2. 增加新功能是否不需要改这个类？（OCP）
  3. 子类替换父类是否安全？（LSP）
  4. 这个接口是否强迫实现类做无用功？（ISP）
  5. 高层依赖的是抽象还是具体？（DIP）

将这些原则内化成肌肉记忆，你便能真正跨越“C++熟练工”与“C++架构师”之间的天堑。至此，SOLID 五原则已完整覆盖，它们将与之前所有的扩展技术一起，成为你构建工业级 C++ 系统的坚实基石。

# c++
Logo
CANN开发者社区

CANN开发者社区旨在汇聚广大开发者，围绕CANN架构重构、算子开发、部署应用优化等核心方向，展开深度交流与思想碰撞，携手共同促进CANN开放生态突破！

更多推荐

cover

09502黄大年茶思屋榜文95期 第2题 高性能、适用于NPU硬件的Training-free大模型剪枝算法

avatar CANN开发者社区
cover

【HarmonyOS 6.0】CANN Kit：PC端大语言模型推理API与计算加速机制解析

avatar CANN开发者社区
cover

Java Programming Chapter 4——Error: An abstract method cannot have a body.

avatar CANN开发者社区