C++如何使用指针实现依赖注入-C++-PHP中文网

依赖注入在c++中常用指针（尤其是std::unique_ptr或std::shared_ptr）是因为只有指针支持运行时多态和动态实现替换：引用不可重绑定，值语义无法多态且引发拷贝；智能指针通过基类指针调用虚函数，确保正确析构（需virtual ~base()），并明确管理对象生命周期，避免裸指针悬空风险。

c++如何使用指针实现依赖注入

依赖注入在C++里为什么常用指针（而非引用或值）

因为依赖注入的核心是「运行时替换实现」，而只有指针（或智能指针）能解耦编译期绑定。引用一旦绑定就不能重绑，值语义会触发拷贝且无法多态；只有 std::unique_ptr 或 std::shared_ptr 能安全持有派生类对象，并通过基类指针调用虚函数。

常见错误现象：std::unique_ptr<base> ptr = std::make_unique<derived>()</derived> 编译失败 → 忘记 Base 必须有虚析构函数；否则 Derived 的析构逻辑不会被调用。

基类接口必须声明 virtual ~Base() = default;
避免裸指针（Base*），它不管理生命周期，容易悬空
若依赖需跨作用域共享，选 std::shared_ptr；否则优先用 std::unique_ptr

如何用 std::unique_ptr 实现构造函数注入

这是最直接、RAII 友好的方式：把依赖作为构造函数参数传入，内部用 std::unique_ptr 存储。对象一创建，依赖就确定且不可变。

class Service {
public:
    virtual void doWork() = 0;
    virtual ~Service() = default;
};
<p>class RealService : public Service {
public:
void doWork() override { /<em> ... </em>/ }
};</p><p>class Client {
std::unique<em>ptr<service> service</service></em>;
public:
explicit Client(std::unique<em>ptr<service> s) : service</service></em>(std::move(s)) {}
void run() { service_->doWork(); }
};
</p>

使用时：Client c{std::make_unique<realservice>()}</realservice>。注意必须用 std::move，否则编译失败（std::unique_ptr 不可拷贝）。

测试时可传入 std::make_unique<mockservice>()</mockservice>，无需修改 Client 定义
不能在构造后替换依赖——这是设计意图，确保状态一致性
如果需要后期替换，得改用 std::shared_ptr + setter，但要额外考虑线程安全

setter 注入为何要慎用 std::shared_ptr

当依赖可能在对象生命周期中变更（如配置热更新、策略切换），会用 setter。此时裸指针风险太高，std::unique_ptr 又不支持重复赋值，所以常选 std::shared_ptr。

C++

"空空如也"

下载

但问题在于：多个 std::shared_ptr 指向同一对象时，引用计数开销虽小，但更隐蔽的风险是循环引用——比如 Client 持有 Service，而 Service 又持有 Client 回调。

避免循环引用：回调场景改用 std::weak_ptr 持有反向引用
setter 中应检查是否为 null：if (s) service_ = std::move(s)，防止意外清空依赖
若 setter 可能被多线程调用，service_ 需加 std::atomic<:shared_ptr>></:shared_ptr> 或锁保护

std::unique_ptr 和 std::shared_ptr 在注入中的性能与语义差异

二者不是性能高低问题，而是所有权语义不同。误用会导致未定义行为或资源泄漏。

典型错误：Client 接收 std::shared_ptr 但内部只读不共享，却因此引入不必要的原子操作和堆分配；或该用 std::shared_ptr 却用了 std::unique_ptr，导致无法在多个组件间传递同一服务实例。

std::unique_ptr：零开销抽象，适合“独占控制权”的依赖（如日志器、数据库连接池管理器）
std::shared_ptr：带引用计数，适合“多方协作”的服务（如全局配置中心、事件总线）
永远不要用 new ServiceImpl + 裸指针注入——生命周期完全失控，静态分析工具（如 clang-tidy）会报 cppcoreguidelines-owning-memory

真正难的不是语法，而是判断一个依赖在系统中究竟该由谁销毁、能否被多个消费者同时持有。这需要结合模块边界和数据流来设计，而不是套模板。