blocks|key|2319185|text|A类可能依赖于3-4其他行为(接口).一方面，将它们全部传递到构造函数中会使对象更难创建和初始化。另一方面，在客户端忘记设置依赖项时，使用setter可能会有问题。什么是正确的方法来处理这件事？
|type|blockquote|depth|inlineStyleRanges|entityRanges|data|2319186|unstyled|2319187|没有完美的解决方案，所以你只需要调整口味。备选方案包括：|2319188|让/a构造函数接受对注入对象进行分组的结构(如果将相同的依赖项集传递给许多构造函数)|unordered-list-item|2319189|划分运行时和编译时之间的依赖关系，并使用派生/using/typedef对编译时依赖项进行分解(+ala现代C%2B%2B设计中的“策略”)|offset|length|style|CODE|2319190|为某些/所有依赖项或某些动态查找“服务”提供默认值，这些“服务”仍然允许您修改注入，但在多个依赖对象构造中保持不变。|2319191|2319192|2319193|对重复的代码进行一些想象和分析，有希望为您提供一种方法.|2319194|最终，必须在某个地方创建所有依赖项。如何防止一个类(例如，主类)中存在多个初始化的情况？
|2319195|2319196|这是一个分解冗余依赖创建和访问对象的问题--您的选择是相似的--传递引用或指针，使用结构或容器或管理对象对它们进行分组和重新访问.|2319197|在进行依赖项注入时使用shared_ptr是否被认为是一种良好的实践？在这种情况下，依赖关系的创建者通常无法删除对象，所以使用共享指针对我来说是有意义的。
|2319198|2319199|对于函数，客户端代码通常比被调用的函数的使用寿命长，因此不需要共享指针.参考资料是理想的。如果您使用线程，或者创建比客户端代码更有效的对象，那么共享指针就很有意义了。|2319200|entityMap^0|0|0|0|0|N|5|T|7|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|-4|5|C|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|C|7|18|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|19|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|1A|8|@$K|1B|L|1C|M|N]|$K|1D|L|1E|M|N]]|9|@]|A|$]]|$1|O|3|P|5|H|7|1F|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|C|7|1G|8|@]|9|@]|A|$]]|$1|R|3|-4|5|C|7|1H|8|@]|9|@]|A|$]]|$1|S|3|T|5|C|7|1I|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1J|8|@]|9|@]|A|$]]|$1|W|3|-4|5|C|7|1K|8|@]|9|@]|A|$]]|$1|X|3|Y|5|C|7|1L|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1M|8|@]|9|@]|A|$]]|$1|11|3|-4|5|C|7|1N|8|@]|9|@]|A|$]]|$1|12|3|13|5|C|7|1O|8|@]|9|@]|A|$]]|$1|14|3|-4|5|C|7|1P|8|@]|9|@]|A|$]]]|15|$]]

<blockquote>
 class A may be dependant on 3-4 other behaviour (interfaces). On the one hand, passing all of them in the constructor makes the object harder to create and initialize. On the other hand, using setters might be problematic in case a client forgot to set one of the dependencies. What would be the correct way to deal with this?
</blockquote>

There's no perfect solution, so you just have to tune to taste. Options include:

<ul>
<li>having the/a constructor accept a structure grouping the injected objects (if you're passing the same set of dependencies to many constructors)</li>
<li>dividing dependencies between run-time and compile-time and having compile-time dependencies factored using derivation/<code>using</code>/<code>typedef</code> ("Policies" ala Modern C++ Design by Alexandrescu)</li>
<li>providing defaults for some/all dependencies, or some dynamic lookup "service" that still lets you modify the injections but persists across multiple dependent-object constructions</li>
</ul>

A bit of imagination and analysis of your repetitive code would hopefully suggest an approach to you....

<blockquote>
 Eventually, all dependencies must be created somewhere. How do i prevent a case in which i have many initialization in one class (for example, the main class) ?
</blockquote>

This is a matter of factoring redundant dependency creation and the access to objects - your choices are similar - passing around references or pointers, using structures or containers or management objects to group them and re-access them....

<blockquote>
 Is it considered a good practice to use shared_ptr when doing dependency injection? In such cases the creator of the dependencies usually could not delete the objects, so it makes sense to me to use shared pointers.
</blockquote>

For functions, often the client code necessarily outlives the use by the function being called so there's no need for shared pointers... a reference is ideal. If you're using threads, or creating objects that can outlive the client code, then shared pointers can make a lot of sense.

blocks|key|2319222|text|所有的个人意见，但我们要走了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2319223|1)将依赖项传递给构造函数。如果存在合理的默认值，则提供多个构造函数或使用默认参数。|2319224|2)如果您要经常使用同一组依赖项，您可以通过创建一个“依赖集”类来保存一些类型，该类的实例可以传递给构造函数，如下所示：|2319225|struct+Iface1;
struct+Iface2;+//+Dependent+interfaces
struct+Iface3;

struct+DependencySet
{
++++Iface1&+iface1;
++++Iface2&+iface2;
++++Iface3&+iface3;
};

class+Dependent
{
public:
++++Dependent(DependencySet&+set)
++++++++:+iface1(set.iface1)
++++++++,+iface2(set.iface2)
++++++++,+iface3(set.iface3)
++++{}

private:
++++Iface1&+iface1;
++++Iface2&+iface2;
++++Iface3&+iface3;
};|code-block|syntax|javascript|2319226|3)就我个人而言，我倾向于像上面那样使用引用并管理生命周期，这样依赖关系就会超过依赖类，但是如果您想要“忘记”一旦使用了依赖项，就可以使用共享指针。|2319227|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|R|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

All personal opinions, but there we go.

1) Pass the dependencies to the constructor. If there are sensible defaults, then provide multiple constructors or use default arguments.

2) If you're going to be using the same set of dependencies frequently, you might be able to save yourself some typing by creating a "dependency set" class, an instance of which can be passed to a constructor, something like:

<pre><code>struct Iface1;
struct Iface2; // Dependent interfaces
struct Iface3;

struct DependencySet
{
 Iface1&amp; iface1;
 Iface2&amp; iface2;
 Iface3&amp; iface3;
};

class Dependent
{
public:
 Dependent(DependencySet&amp; set)
 : iface1(set.iface1)
 , iface2(set.iface2)
 , iface3(set.iface3)
 {}

private:
 Iface1&amp; iface1;
 Iface2&amp; iface2;
 Iface3&amp; iface3;
};
</code></pre>

3) Personally I'd favour using references as above and managing the lifetimes so that the dependencies outlive the dependent class, but shared pointers could be used if you want to "forget" about the dependencies once you've used them.

I am practicing dependency injection and there are several issues that i am not sure how to deal with them.

<ol>
<li>class A may be dependant on 3-4 other behaviour (interfaces). On the one hand, passing all of them in the constructor makes the object harder to create and initialize. On the other hand, using setters might be problematic in case a client forgot to set one of the dependencies. What would be the correct way to deal with this?</li>
<li>Eventually, all dependencies must be created somewhere. How do i prevent a case in which i have many initialization in one class (for example, the main class) ?</li>
<li>Is it considered a good practice to use shared_ptr when doing dependency injection? In such cases the creator of the dependencies usually could not delete the objects, so it makes sense to me to use shared pointers.</li>
</ol>

Several questions regarding Dependency Injection in C++

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在练习依赖注入，有几个问题我不知道如何处理。A类可能依赖于3-4其他行为(接口).一方面，将它们全部传递到构造函数中会使对象更难创建和初始化。另一方面，在客户端忘记设置依赖项时，使用setter可能会有问题。什么是正确的方法来处理这件事？最终，必须在某个地方创建所有依赖项。如何防止一个类(例如，主类)中存在多个初始...

问关于C++中依赖注入的几个问题
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问关于C++中依赖注入的几个问题EN