C++ 依赖注入(inject) : Object lifetimes?

Question

我来自 C#，并试图将我的一些实践转化为 C++。我在我的代码中的各个地方使用原始指针使用依赖注入(inject)。然后我决定用 std::shared_ptr 替换原始指针。作为该过程的一部分，有人建议我考虑使用堆栈分配的自动变量而不是动态分配它们(请参阅 this question 尽管该问题是在 unique_ptr 的上下文中进行的，所以可能有所不同)。

我相信下面的例子展示了自动变量的使用。

class MyClass
{ 
public:
   MyClass(ApplicationService& app): appService_(app)
   {
   }

   ~MyClass()
   {
        appService_.Destroy(something);

   }
private:   
   ApplicationService& appService_;
}

class ConsumerClass
{
    DoSomething()
    {
        CustomApplicationService customAppService;
        MyClass myclass(customAppService);
        myclass...
    }
}

在上面的例子中，当 customAppservice 和 myclass 超出范围时，我怎么知道哪个先被销毁？如果 customAppService 首先被销毁，则 MyClass 析构函数将失败。这是在这种情况下改用 shared_ptr 的充分理由，还是有解决此问题的干净方法？

更新

ApplicationService 是一个类，它是与我的代码使用的第 3 方库交互所需的全局函数的包装器。我有这个类(class)，因为我相信这是支持独立功能的单元测试和 stub /模拟的标准方法。此类只是将调用委托(delegate)给相应的全局函数。调用 appService_.Destroy(something);实际上是销毁 MyClass 的每个特定实例使用的对象，而不是销毁与 Application 类本身有关的任何内容。

Answer 1

答案是:您不需要知道，因为您的设计无论如何都已损坏。

首先，Destroy 听起来不是个好主意，而且如果在不负责销毁其他对象的对象中调用。 Destroy 方法中的代码属于 ApplicationService 的析构函数(希望它是虚拟的，尽管在这种情况下它实际上不需要)，这与 C# 不同在完全确定的时间点被调用。

完成此操作后，您将(希望)意识到，销毁 appService_ 不是 MyClass 的责任，因为它不拥有它.这是 ConsumerClass(或者更确切地说是 DoSomething 方法)的责任，它真正管理实际的服务，并且在您移动 后实际上会自动销毁它Destroy的代码进入析构函数。 RAII 以干净和自动的方式让一切发生，这不是很好吗？

class MyClass
{ 
public:
   MyClass(ApplicationService& app): appService_(app)
   {
   }

private:   
   ApplicationService& appService_;
}

class ConsumerClass
{
    DoSomething()
    {
        CustomApplicationService customAppService;
        MyClass myclass(customAppService);
        myclass...
    }
}

class ApplicationService
{
public:
    virtual ~ApplicationService()
    {
        //code from former Destroy method
    }
}

class CustomApplicationService
{
public:
    virtual ~CustomApplicationService()
    {
        //code from former Destroy method
    }
}

恕我直言，这是绕过它的完美干净的 C++ 方法，这个问题绝对不是垃圾邮件 shared_ptr 的理由。即使你真的需要一个专用的 Destroy 方法并且不能将代码移到析构函数中(我认为这是过度考虑设计的动机)，那么你仍然会调用 Destroy 同样来自 DoSomething，MyClass 不负责销毁 appService_。

编辑:根据您的更新(以及我对 something 参数的愚蠢忽略)，您的设计似乎确实非常正确(至少如果您不能乱改ApplicationService), 抱歉。

虽然类成员应该以相反的构造顺序销毁，但我不确定这是否也适用于局部自动变量。为确保按定义的顺序调用析构函数，您可以做的是使用简单的 block 引入嵌套范围:

void DoSomething()
{
    CustomApplicationService customAppService;
    {
        MyClass myclass(customAppService);
        myclass...
    }       // myclass destroyed
}       // customAppService destroyed

当然还是完全没有必要使用动态分配，且不说shared_ptr。尽管嵌套 block 有点破坏代码，但这并没有抵制以非动态方式应用的动态分配的丑陋，并且没有理由而且它至少“在语义上看起来不错” customAppService block 顶部的声明 ;)