正确构造和销毁注入的Setter依赖关系对象(可能使用qt)
我正在使用QT，所以可能有更高级的选项或最佳实践方法。但如果有一个好的，一般的C++或语言不可知论的答案，那将是最可怕的！
我试图正确地构造和销毁由setter依赖注入配置的对象，并对对象的生命周期进行规划。
在德国微软博客上，这是一个很好的比喻，用来讨论对象之间的d依赖关系、责任和交互，我想对此进行调整：
有一位硕士和一位学徒-园丁
主人想让学徒挖洞。一开始，学徒是用铲子建造的，所以他可以挖，但有人指责说，创造一个自己的铲子对一个学徒来说责任太大了。
现在，在第二种方法，大师可以进入一个漂亮的铲子工厂，生产质量，可测试的铲子。他继续说，告诉digWith(testableShovel)的学徒。
现在，在Setter Dependendy Injection的上下文中，我会让主人告诉学徒takeShovel(testableShovel) (赛特)，然后diggBoy()让他挖洞。
当师父忘记告诉徒弟拿铲子时，问题就来了，因为现在学徒没有工具可挖了。
为了处理这件事，我想知道学徒在建筑中创造自己非常基本的挖掘设备(比如一双手)合适吗？或者应该通过构造函数依赖注入(同时允许构造函数和依赖项注入)来实现？是创造/带着一双手对学徒提出了更多的要求，而我应该拥有一个nullptr-check吗？
现在，让我们假设我的学徒创造了他自己的一双手，谁会摧毁他们，一旦他拿起铲子？一旦他丢下铲子，谁会再创造它们呢？如果把学徒放在一边，什么会被摧毁？
回答 1
Stack Overflow用户
发布于 2017-08-16 07:30:22
对于第一个问题:如果目标对象需要被注入的对象来完成它的工作，那么它应该被注入构造函数中。否则，在构造后，对象将处于无效状态。或者，如果在目标中执行某些依赖项的“基本”版本，那么首先要引入依赖注入试图避免的耦合。另一方面，如果依赖关系在某种程度上是可选的(例如，在某些情况下，记录器可以被认为是可选的)，那么setter注入是完全可以的。
第二，我认为通过setter依赖注入赋予其他对象的对象的所有权将取决于上下文。如果注入的对象是其他人不会使用的东西，那么将它的std::unique_ptr传输到目标。另一方面，如果其他人要使用它，那么您可能会有一个std::shared_ptr引用。这里的关键是使用现代的“智能”指针来发出信号并强制执行注入对象的所有权。
https://stackoverflow.com/questions/45707248
复制相似问题
腾讯云开发者
