CPP学习笔记—依赖注入

依赖注入 (Dependency Injection, DI)。这是一个在现代软件工程中至关重要的概念，尤其是在构建大型、可维护和可测试的系统中。

1. 什么是依赖？什么是问题所在？

在面向对象编程中，一个类（或对象）通常需要依赖其他类（或对象）来完成其工作。这种“需要”就是依赖。

问题代码（紧密耦合）：

让我们从一个没有使用依赖注入的例子开始。假设我们有一个 Car 类，它需要一个 Engine 和一个 Logger 来工作。

#include <iostream>
#include <string>

// 依赖 1: 具体的 V8 引擎
class V8Engine {
public:
    void start() {
        std::cout << "V8 Engine starts. Vroom Vroom!" << std::endl;
    }
};

// 依赖 2: 具体的控制台日志记录器
class ConsoleLogger {
public:
    void log(const std::string& message) {
        std::cout << "[LOG]: " << message << std::endl;
    }
};

// Car 类，自己创建并管理它的依赖
class Car {
private:
    V8Engine engine_;
    ConsoleLogger logger_;

public:
    Car() {
        // Car 内部直接创建了它的依赖对象
        // 这就是紧密耦合！
        // engine_ = V8Engine();
        // logger_ = ConsoleLogger();
        logger_.log("Car has been created.");
    }

    void start() {
        logger_.log("Attempting to start the car.");
        engine_.start();
        logger_.log("Car started successfully.");
    }
};

int main() {
    Car myCar;
    myCar.start();
    return 0;
}

这段代码看起来很简单，而且能工作。但它存在几个严重的问题：

紧密耦合 (Tight Coupling)：Car 类直接依赖于 V8Engine 和 ConsoleLogger 这两个具体的类。Car 的代码写死了它必须使用 V8 引擎和控制台日志。
难以测试 (Hard to Test)：如何对 Car 类进行单元测试？我们只想测试 Car 的 start 逻辑，但它会自动调用 V8Engine::start 和 ConsoleLogger::log。我们无法在测试中“模拟”（Mock）一个引擎的行为（比如，测试引擎启动失败的情况），也无法验证日志是否被正确调用，因为它们都是硬编码在 Car 内部的。
缺乏灵活性和可扩展性 (Inflexible and Not Extensible)：如果我想给这辆车换一个 ElectricEngine（电动引擎）怎么办？或者，我希望日志不是输出到控制台，而是写入文件（FileLogger）？唯一的办法就是修改 Car 类的源代码。这违反了开闭原则（对扩展开放，对修改关闭）。

2. 核心思想：控制反转 (Inversion of Control, IoC) 与依赖注入 (DI)

为了解决上述问题，我们引入了控制反转 (Inversion of Control, IoC) 的概念。

传统控制流程：Car 类自己负责创建和管理它所依赖的 Engine 和 Logger 对象。Car 控制着一切。
控制反转：Car 类不再自己创建依赖，而是被动地接收这些依赖。创建依赖的“控制权”从 Car 内部反转到了 Car 的外部。

依赖注入 (Dependency Injection, DI) 是实现控制反转最常见和最主要的方式。

DI 的核心定义：不要在类内部创建依赖，而是通过外部（调用者）将依赖传递（注入）给它。

3. DI 的实现方式

在 C++ 中，主要有三种实现依赖注入的方式。为了让 DI 发挥最大作用，我们通常会结合面向接口编程（即依赖于抽象而不是具体实现）。

首先，定义我们需要的抽象接口：

#include <iostream>
#include <string>
#include <memory>

// 抽象接口 1: IEngine
class IEngine {
public:
    virtual ~IEngine() = default;
    virtual void start() = 0;
};

// 抽象接口 2: ILogger
class ILogger {
public:
    virtual ~ILogger() = default;
    virtual void log(const std::string& message) = 0;
};

然后，我们提供这些接口的具体实现：

// 具体实现
class V8Engine : public IEngine {
public:
    void start() override { std::cout << "V8 Engine starts. Vroom Vroom!" << std::endl; }
};

class ElectricEngine : public IEngine {
public:
    void start() override { std::cout << "Electric Engine starts. Bzzzzzz!" << std::endl; }
};

class ConsoleLogger : public ILogger {
public:
    void log(const std::string& message) override { std::cout << "[CONSOLE LOG]: " << message << std::endl; }
};

class FileLogger : public ILogger {
private:
    std::string filePath_;
public:
    FileLogger(std::string path) : filePath_(std::move(path)) {}
    void log(const std::string& message) override { 
        // 伪代码: 将 message 写入到 filePath_ 文件
        std::cout << "[FILE LOG to " << filePath_ << "]: " << message << std::endl;
    }
};

现在，我们重构 Car 类，使其依赖于 IEngine 和 ILogger 接口，并使用 DI 来接收具体的实现。

方式一：构造函数注入 (Constructor Injection)

这是最常用、也是最推荐的方式。依赖通过类的构造函数传入。

// Car 类现在依赖于抽象接口，而不是具体类
class Car {
private:
    std::unique_ptr<IEngine> engine_; // 使用智能指针管理生命周期
    std::shared_ptr<ILogger> logger_; // Logger 可能被多处共享，用 shared_ptr

public:
    // 依赖通过构造函数注入
    Car(std::unique_ptr<IEngine> engine, std::shared_ptr<ILogger> logger)
        : engine_(std::move(engine)), logger_(std::move(logger)) {
        if (!engine_ || !logger_) {
            throw std::invalid_argument("Engine and Logger must not be null.");
        }
        logger_->log("Car has been created with injected dependencies.");
    }

    void start() {
        logger_->log("Attempting to start the car.");
        engine_->start();
        logger_->log("Car started successfully.");
    }
};

// --- 客户端代码 (main 函数) ---
int main() {
    // 外部负责创建具体的依赖对象
    auto logger = std::make_shared<ConsoleLogger>();

    std::cout << "--- Building a Gas Car ---" << std::endl;
    auto v8_engine = std::make_unique<V8Engine>();
    // 将依赖注入到 Car 中
    Car gasCar(std::move(v8_engine), logger);
    gasCar.start();

    std::cout << "\n--- Building an Electric Car ---" << std::endl;
    auto electric_engine = std::make_unique<ElectricEngine>();
    // 注入不同的依赖，创建不同行为的对象，而 Car 类完全不用修改
    Car electricCar(std::move(electric_engine), logger);
    electricCar.start();
    
    return 0;
}

优点：
- 依赖明确：构造函数清晰地声明了该类需要哪些依赖才能工作。
- 保证有效状态：一旦对象被构造出来，它就处于一个完整的、可用的状态，因为所有必需的依赖都已提供。
- 不变性：依赖一旦被注入，通常在对象的生命周期内是不可变的。
缺点：
- 如果依赖项过多，构造函数会变得很长，很笨重。
- 不适用于有循环依赖的场景（A 依赖 B，B 依赖 A）。

方式二：Setter 注入 (Setter/Method Injection)

通过公有的 setter 方法来注入依赖。

class Car {
private:
    std::unique_ptr<IEngine> engine_;
    std::shared_ptr<ILogger> logger_;

public:
    Car() = default; // 允许创建一个 "不完整" 的对象

    void setEngine(std::unique_ptr<IEngine> engine) {
        engine_ = std::move(engine);
    }

    void setLogger(std::shared_ptr<ILogger> logger) {
        logger_ = std::move(logger);
    }

    void start() {
        if (logger_) logger_->log("Attempting to start the car.");
        if (engine_) {
            engine_->start();
        } else {
            if (logger_) logger_->log("Error: Engine not set!");
        }
        if (logger_) logger_->log("Car start sequence finished.");
    }
};

// --- 客户端代码 ---
int main() {
    auto logger = std::make_shared<FileLogger>("car_log.txt");

    Car myCar; // 创建时没有依赖
    myCar.setLogger(logger); // 注入 Logger
    myCar.setEngine(std::make_unique<V8Engine>()); // 注入 Engine
    
    myCar.start();
    return 0;
}

优点：
- 灵活性高：可以在对象的生命周期内随时更改依赖。
- 适用于可选依赖：如果某个依赖不是必需的，Setter 注入是很好的选择。
- 可以解决循环依赖问题。
缺点：
- 状态不确定：对象在调用 setter 方法前，可能处于一个不完整的、不可用的状态。需要在使用前进行检查（如 if (engine_)）。
- 依赖关系不明确：不查看代码，无法一眼看出这个类到底需要哪些依赖。

方式三：接口注入 (Interface Injection)

定义一个注入接口，让需要被注入的类实现这个接口。这种方式在 C++ 中不太常用，在 Java 或 C# 等语言中更常见一些。

// 定义注入接口
template<typename T>
class IInjectable {
public:
    virtual ~IInjectable() = default;
    virtual void inject(T dependency) = 0;
};

// Car 实现注入接口
class Car : public IInjectable<std::shared_ptr<ILogger>>,
            public IInjectable<std::unique_ptr<IEngine>> {
private:
    std::unique_ptr<IEngine> engine_;
    std::shared_ptr<ILogger> logger_;

public:
    void inject(std::unique_ptr<IEngine> engine) override {
        engine_ = std::move(engine);
    }
    void inject(std::shared_ptr<ILogger> logger) override {
        logger_ = std::move(logger);
    }
    // ... start() 方法 ...
};

优点：可以精确地控制注入哪种类型的依赖。
缺点：侵入性强，需要让类继承特定的注入接口，增加了代码的复杂度和耦合度。在 C++ 中很少使用。

4. 依赖注入的巨大优势

现在我们回头看，DI 到底解决了什么问题？

解耦 (Decoupling)：Car 类不再与 V8Engine 或 ConsoleLogger 耦合，而是与 IEngine 和 ILogger 接口耦合。这被称为依赖倒置原则 (Dependency Inversion Principle, DIP) - “高层模块不应该依赖于低层模块，两者都应该依赖于抽象”。

极强的可测试性 (Superior Testability)：这是 DI 最重要的优点之一！我们可以轻松地为 Car 编写单元测试。

// --- 单元测试示例 (使用 Google Test 框架的伪代码) ---
#include <gtest/gtest.h>
#include <gmock/gmock.h>

// 1. 创建 Mock 对象
class MockEngine : public IEngine {
public:
    MOCK_METHOD(void, start, (), (override)); // 使用 GMock 宏
};

class MockLogger : public ILogger {
public:
    MOCK_METHOD(void, log, (const std::string& message), (override));
};

// 2. 编写测试用例
TEST(CarTest, Start_CallsEngineStartAndLogsCorrectly) {
    // Arrange: 准备测试环境
    auto mockEngine = std::make_unique<MockEngine>();
    auto mockLogger = std::make_shared<MockLogger>();

    // 设置 Mock 对象的预期行为
    EXPECT_CALL(*mockEngine, start()).Times(1); // 期望 start() 被调用一次
    EXPECT_CALL(*mockLogger, log(testing::_)).Times(testing::AtLeast(1)); // 期望 log() 被调用至少一次

    // Act: 执行被测试的操作
    Car car(std::move(mockEngine), mockLogger);
    car.start();

    // Assert: GTest 和 GMock 会自动验证 EXPECT_CALL 是否满足
}

在这个测试中，我们完全控制了 Car 的依赖，可以验证 Car 是否正确地调用了它们，而不需要一个真正的引擎或日志系统。

高度的灵活性和可重用性 (Flexibility & Reusability)：如 main 函数所示，我们可以像搭积木一样，将不同的引擎和日志记录器组合起来，创建出不同行为的 Car 对象，而 Car 类本身一行代码都不用改。

5. 应用场合

依赖注入几乎适用于所有中大型项目，特别是当你希望代码是松耦合、可维护、可测试的时候。

单元测试：如上所示，这是 DI 的“杀手级应用”。如果你想对一个类进行隔离测试，DI 是必经之路。
跨平台/环境开发：你的应用可能需要运行在不同环境下。例如，一个数据访问层，在生产环境可能使用 PostgreSQLDatabase，但在测试环境使用 InMemoryDatabase。通过 DI，你可以在程序启动时根据配置注入不同的数据库实现。
策略模式的实现：当你需要动态地切换算法或策略时。例如，一个 PaymentProcessor 类，可以根据用户选择，注入 CreditCardPaymentStrategy 或 PayPalPaymentStrategy。
处理横切关注点 (Cross-Cutting Concerns)：像日志、缓存、事务管理、权限验证等功能，它们通常散布在系统的各个角落。通过 DI，你可以很容易地将一个 ILogger 或 ICacheProvider 注入到任何需要它的服务中。
插件式或模块化架构：主应用程序定义接口，各个插件模块实现这些接口。主程序通过 DI 来加载和使用这些插件，而无需知道插件的具体实现。

6. DI 容器 (DI Containers)

在大型项目中，手动创建和注入所有依赖会变得非常繁琐和复杂，这个过程被称为组合根 (Composition Root)。

// 在一个大型应用的 main 函数中，可能会是这样：
auto dbConfig = loadConfig("db.json");
auto dbConnection = std::make_shared<PostgreSQLConnection>(dbConfig);
auto userRepository = std::make_shared<UserRepository>(dbConnection);
auto logger = std::make_shared<FileLogger>("app.log");
auto authService = std::make_shared<AuthService>(userRepository, logger);
auto app = Application(authService, logger);
app.run();

当依赖关系图变得复杂时，手动管理变得困难。这时DI 容器（也叫 IoC 容器）就派上用场了。

DI 容器是一个框架，它可以自动地管理对象的创建和依赖注入。你只需要告诉容器：

“当我需要一个 ILogger 时，请给我一个 FileLogger 的实例。”（服务注册）
“请给我创建一个 Application 的实例。”（服务解析）

容器会自动分析 Application 的构造函数，发现它需要 IAuthService 和 ILogger，然后它会去创建这些依赖（并递归地创建依赖的依赖），最后将它们全部组装好并返回给你。

C++ 中虽然没有像 Java Spring 或 .NET Core 那样内置的 DI 容器，但有很多优秀的第三方库，例如：

Boost.DI
Google Fruit

使用 DI 容器的代码（以 Boost.DI 为例的伪代码）：

#include <boost/di.hpp>
namespace di = boost::di;

// ... (接口和类定义) ...

int main() {
    // 1. 创建和配置注射器 (injector)
    const auto injector = di::make_injector(
        di::bind<ILogger>().to<FileLogger>(), // 绑定接口到具体实现
        di::bind<IEngine>().to<V8Engine>(),
        di::bind<std::string>().named("log_path").to("app.log") // 注入配置参数
    );

    // 2. 从容器中创建对象
    // 容器会自动解决 Car 的所有依赖
    auto car = injector.create<Car>(); 
    car.start();
    
    return 0;
}