正确构造和销毁 Setter 依赖注入对象(可能使用 qt）

Correct Construction and Destruction of Setter Dependency Injected Objects (maybe with qt)

本文关键字：对象 qt 注入依赖 Setter 更新时间：2023-10-16

我正在使用QT，所以也许有更高级的选项或最佳实践方法。但是，如果有一个好的、通用的、与C++或语言无关的答案，那就太棒了！

我尝试正确构造和销毁由setter 依赖注入配置的对象，并且很难规划对象的生命周期。

在德国Microsoft博客上，有一个很好的比喻来讨论对象的依赖关系、职责和交互，我想改编一下：

有一个师傅-园丁和一个学徒-园丁
师傅要学徒去挖。一开始，学徒是用铲子建造的，所以他可以挖，但有人指责，制造自己的铲子对学徒来说责任太大了。

现在，在第二种方法中，主人可以使用一个漂亮的铲子工厂，生产优质，可测试的铲子。他继续说，告诉徒弟digWith(testableShovel)。

现在在二传手依赖注射的背景下，我会让师傅告诉学徒takeShovel(testableShovel)(二传手(，然后diggBoy()让他挖掘。

问题来了，师傅忘了告诉徒弟拿铁锹，就像现在学徒没有工具可以挖一样。

为了处理这种情况，我想知道 - 学徒在建造时创建自己的非常基本的挖掘设备(例如一双手(是否合适？还是应该通过构造函数依赖注入(允许构造函数和依赖注入(来完成？创造/带一双手对徒弟的要求很大，我宁愿有一个nullptr检查？

现在，让我们假设我的徒弟创造了自己的一双手，一旦他拿起铲子，谁会摧毁它们？一旦他放下铲子，谁来重新创建它们？如果学徒被搁置一旁，什么会被摧毁？

对于你的第一个问题：如果目标对象需要注入的对象来完成它的工作，那么它应该被注入到构造函数中。否则，对象在构造后将处于无效状态。或者，如果您在目标中执行某些依赖项的"基本"版本，那么您将引入依赖项注入首先试图避免的耦合。另一方面，如果依赖关系在某种程度上是可选的(例如，在某些情况下记录器可以被认为是可选的(，那么 setter 注入是完全可以的。

其次，我认为通过 setter 依赖注入提供给其他对象的对象的对象的所有权将取决于上下文。如果注入的对象是其他人不会使用的对象，则将std::unique_ptr对象转移到目标。另一方面，如果其他人会使用它，那么你很可能会有一个std::shared_ptr引用它。这里的关键是，使用现代"智能"指针将发出信号并强制执行注入对象的所有权。