C++ Dependency Injection依赖注入模式实现代码正确性咨询

第一版代码问题 #

第一版代码没有实现依赖注入，本质只是C++多态的基础用法：

• 依赖注入的核心逻辑是：如果A类依赖B类的能力，A类不在内部自己创建B的实例，而是由外部把符合抽象规范的依赖实例传入A，实现依赖和业务逻辑的解耦。
• 第一版代码里不存在持有依赖的业务主体，只有ICar抽象接口、两个具体实现类，再加一个接收ICar引用的全局函数displayInfo，完全没有「外部向依赖方注入实例」的过程，不符合依赖注入的定义。

第二版代码结论 #

你修改后的第二版代码已经正确实现了最常用的构造函数式依赖注入，核心逻辑完全符合要求：

• 你把引擎能力抽象成了IEngine接口，Car类作为依赖引擎的业务主体，没有在类内部写死创建某款具体引擎的逻辑，而是通过构造函数接收外部传入的IEngine类型实例。后续要给车换不同参数的引擎，只要新增IEngine的实现类，在外部创建实例后传入Car即可，不需要修改Car类的代码，已经达到了依赖注入解耦的核心目的。

可优化的细节 #

当前代码还有几个工程实践上可以调整的地方，不影响依赖注入的正确性，但能让代码更健壮：

• 代码中用new创建的EngineTDI和Car实例没有手动释放，会造成内存泄漏。实际开发中建议用std::unique_ptr/std::shared_ptr这类智能指针管理堆内存，避免遗漏资源释放。
• 构造函数参数和成员变量同名、用this指针区分的写法可读性较差，可以给成员变量加统一前缀（比如m_开头），配合构造函数初始化列表写，逻辑更清晰，参考写法：

class Car
{
private:
    IEngine* m_engine;
public:
    Car(IEngine* engine) : m_engine(engine) {}
    void showCapacity()
    {
        m_engine->engineCapacity();
    }
};

• 依赖注入除了你现在用的构造函数注入，还有Setter注入（通过成员方法传入依赖）、接口注入两种常见形式，但构造函数注入是日常开发里最通用、最推荐的写法，你当前的实现已经可以满足绝大多数场景的使用需求。

内容的提问来源于stack exchange，提问作者Hubertm998