如何在c++中实现依赖注入(Dependency Injection)？ (解耦设计模式)_技术教程

C++依赖注入需手动实现，核心是接口抽象+构造函数注入+智能指针管理；避免内部new和全局单例，优先用std::shared_ptr共享依赖，慎用第三方DI容器。

在 C++ 中无法像 Java 或 C# 那样靠语言级注解或运行时反射自动完成依赖注入，必须手动管理对象生命周期和依赖关系。核心思路是：用抽象（接口）隔离实现，用构造函数或 setter 显式传入依赖，再配合工厂、智能指针或轻量级容器控制创建时机。

用纯虚类定义接口 + 构造函数注入

这是最直接、无第三方库的方式，适合中等规模项目。关键不是“注入”本身，而是避免 new 硬编码和全局单例。

常见错误现象：类内部直接 new ConcreteService()，导致无法替换实现、难以单元测试。

定义纯虚接口（如 ILogger），所有实现类继承它
依赖方（如 Processor）只持有 std::unique_ptr 或引用，通过构造函数接收
创建时由上层决定传哪个实现：Processor p{std::make_unique()}
不要在构造函数里做耗时操作或抛异常——这会让注入点变得脆弱

用 std::shared_ptr + 工厂函数解耦生命周期

当多个组件共享同一依赖实例（如配置管理器、数据库连接池），且生命周期需统一管理时，std::shared_ptr 比裸指针或 unique_ptr 更合适。

使用场景：日志器、配置服务、HTTP 客户端等跨模块共享对象。

工厂函数返回 std::shared_ptr，而非具体类型
所有使用者拿到的是同一份引用计数的实例，无需关心谁释放
注意循环引用：若 A 持有 shared_ptr 且 B 持有 shared_ptr，需对其中一方改用 weak_ptr
工厂内可读配置、选实现（如根据 ENV=prod 返回 ProdDatabase）

避免过度设计：什么时候不该用 DI 容器？

C++ 项目引入 boost.di 或 GracefulDI 等第三方 DI 库前，先确认是否真需要——它们会增加编译时间、模板膨胀和调试难度。

容易踩的坑：

把简单工具类（如 StringUtils、JsonParser）也塞进容器，反而让调用路径不透明
容器注册逻辑分散在多个 cpp 文件，启动时才发现依赖缺失或类型不匹配（C++ 编译期不报错，链接期才失败）
误以为“自动注入”能替代清晰的职责划分——如果一个类需要 7 个依赖，大概率它违反了单一职责原则
在嵌入式或实时系统中滥用动态内存分配（DI 容器内部常隐式 new 对象）

最小可行示例：构造函数注入 + shared_ptr 管理

以下代码展示如何不用任何第三方库，实现可测试、可替换的日志依赖：

#include 
#include 
#include struct ILogger {
virtual ~ILogger() = default;
virtual void 
log(const std::string& msg) = 0;
};
struct ConsoleLogger : public ILogger {
void log(const std::string& msg) override {
std::cout << "[CONSOLE] " << msg << "\n";
}
};
struct FileLogger : public ILogger {
explicit FileLogger(const std::string& path) : m_path(path) {}
void log(const std::string& msg) override {
std::cout << "[FILE:" << m_path << "] " << msg << "\n";
}
private:
std::string m_path;
};
struct Service {
explicit Service(std::shared_ptr logger) : m_logger(std::move(logger)) {}
void doWork() { m_logger->log("processing..."); }
private:
std::shared_ptr m_logger;
};
// 使用方式
int main() {
auto logger = std::make_shared();
Service svc(logger);
svc.doWork(); // 输出 [CONSOLE] processing...
}