3 rephrasing
source | link

I meant to write this as a comment, but it turned out to be too long.

How I know that Foobar is the only owner? In the old case it's simple. But the problem with DI, as I see it, is as it decouples class from construction of its dependencies, it also decouples it from ownership of those dependencies (as ownership is tied to construction). In garbage collected environments such as Java, that's not a problem. In C++, this is.

Whether you should use std::unique_ptr<Widget> or std::shared_ptr<Widget>, that is up to you to decide and comes from your functionality.

Let's assume you have a Utilities::Factory, which is responsible for the creation of your blocks, such as Foobar. Following the DI principle, you will need the Widget instance, to inject it using Foobar's constructor, meaning inside one of the Utilities::Factory's method, let's sayfor example createWidget(const std::vector<std::string>& params) const, you create the the Widget and inject it into the Foobar classobject.

Now you have a Utilities::Factory method, which created the the Widget object. Does it mean, the method should me responsible for it'sits deletion? Of course not. It is only there to make you the instance.


Let's imagine, you are developing an application, which will have multiple windows. Each window is represented using the Foobar class, so in fact the Foobar acts like a controller.

The controller will probably make use of some of your Widgets and you have to ask yourself:

If I go on this specific window in my application, I will need these Widgets. Are these widgets shared among other application windows? If so, I shouldn't probably be probably creating them all over again, because they will always look the same, because they are shared.

std::shared_ptr<Widget> is your friendthe way to go.

You also have an application window, where there is a Widget specifically tied to this one window only, meaning it won't be showingdisplayed anywhere else. So if you close the window, you don't need the Widget anywhere in your application anymore, or at least it'sits instance.

That's where std::unique_ptr<Widget> comes to claim its throne.


Update:

I don't really agree with @DominicMcDonnell, about the lifetime issue. Calling std::move on std::unique_ptr completely transfers the ownership, so even if you create an object A in a method and pass it to another object B as a dependency, the object B will now be responsible for the resource of object A and will correctly delete it, when object B goes out of scope.

I meant to write this as a comment, but it turned out to be too long.

How I know that Foobar is the only owner? In the old case it's simple. But the problem with DI, as I see it, is as it decouples class from construction of its dependencies, it also decouples it from ownership of those dependencies (as ownership is tied to construction). In garbage collected environments such as Java, that's not a problem. In C++, this is.

Whether you should use std::unique_ptr<Widget> or std::shared_ptr<Widget>, that is up to you to decide and comes from your functionality.

Let's assume you have a Utilities::Factory, which is responsible for the creation of your blocks, such as Foobar. Following the DI principle, you will need the Widget instance, to inject it using Foobar's constructor, meaning inside one of the Utilities::Factory's method, let's say createWidget(const std::vector<std::string>& params) const, you create the the Widget and inject it into the Foobar class.

Now you have a Utilities::Factory method, which created the the Widget object. Does it mean, the method should me responsible for it's deletion? Of course not. It is only there to make you the instance.


Let's imagine, you are developing an application, which will have multiple windows. Each window is represented using the Foobar class, so in fact the Foobar acts like a controller.

The controller will probably make use of some of your Widgets and you have to ask yourself:

If I go on this specific window in my application, I will need these Widgets. Are these widgets shared among other application windows? If so, I shouldn't probably be creating them all over again, because they will always look the same, because they are shared.

std::shared_ptr<Widget> is your friend.

You also have an application window, where there is a Widget specifically tied to this one window only, meaning it won't be showing anywhere else. So if you close the window, you don't need the Widget anywhere in your application anymore, or at least it's instance.

That's where std::unique_ptr<Widget> comes to claim its throne.


Update:

I don't really agree with @DominicMcDonnell, about the lifetime issue. Calling std::move on std::unique_ptr completely transfers the ownership, so even if you create an object A in a method and pass it to another object B as a dependency, the object B will now be responsible for the resource of object A and will correctly delete it, when object B goes out of scope.

I meant to write this as a comment, but it turned out to be too long.

How I know that Foobar is the only owner? In the old case it's simple. But the problem with DI, as I see it, is as it decouples class from construction of its dependencies, it also decouples it from ownership of those dependencies (as ownership is tied to construction). In garbage collected environments such as Java, that's not a problem. In C++, this is.

Whether you should use std::unique_ptr<Widget> or std::shared_ptr<Widget>, that is up to you to decide and comes from your functionality.

Let's assume you have a Utilities::Factory, which is responsible for the creation of your blocks, such as Foobar. Following the DI principle, you will need the Widget instance, to inject it using Foobar's constructor, meaning inside one of the Utilities::Factory's method, for example createWidget(const std::vector<std::string>& params), you create the Widget and inject it into the Foobar object.

Now you have a Utilities::Factory method, which created the Widget object. Does it mean, the method should me responsible for its deletion? Of course not. It is only there to make you the instance.


Let's imagine, you are developing an application, which will have multiple windows. Each window is represented using the Foobar class, so in fact the Foobar acts like a controller.

The controller will probably make use of some of your Widgets and you have to ask yourself:

If I go on this specific window in my application, I will need these Widgets. Are these widgets shared among other application windows? If so, I shouldn't be probably creating them all over again, because they will always look the same, because they are shared.

std::shared_ptr<Widget> is the way to go.

You also have an application window, where there is a Widget specifically tied to this one window only, meaning it won't be displayed anywhere else. So if you close the window, you don't need the Widget anywhere in your application anymore, or at least its instance.

That's where std::unique_ptr<Widget> comes to claim its throne.


Update:

I don't really agree with @DominicMcDonnell, about the lifetime issue. Calling std::move on std::unique_ptr completely transfers the ownership, so even if you create an object A in a method and pass it to another object B as a dependency, the object B will now be responsible for the resource of object A and will correctly delete it, when object B goes out of scope.

2 edited body
source | link

I meant to write this as a comment, but it turned out to be too long.

How I know that Foobar is the only owner? In the old case it's simple. But the problem with DI, as I see it, is as it decouples class from construction of its dependencies, it also decouples it from ownership of those dependencies (as ownership is tied to construction). In garbage collected environments such as Java, that's not a problem. In C++, this is.

Whether you should use std::unique_ptr<Widget> or std::shared_ptr<Widget>, that is up to you to decide and comes from your functionality.

Let's assume you have a Utilities::Factory, which is responsible for the creation of your blocks, such as Foobar. Following the DI principle, you will need the Widget instance, to inject it using Foobar's constructor, meaning inside one of the Utilities::Factory's method, let's say createWidget(const std::vector<std::string>& params) const, you create the the Widget and inject it into the Foobar class.

Now you have a Utilities::Factory method, which created the the Widget object. Does it mean, the method should me responsible for it's deletion? Of course not. It is only there to make you the instance.


Let's imagine, you are developing an application, which will have multiple windows. Each window is represented using the Foobar class, so in fact the Foobar acts like a controller.

The controller will probably make use of some of your Widgets and you have to ask yourself:

If I go on this specific window in my application, I will need these Widgets. Are these widgets shared among other application windows? If so, I shouldn't probably be creating them all over again, because they will always look the same, because they are shared.

std::shared_ptr<Widget> is your friend.

You also have an application window, where there is a Widget specifically tied to this one window only, meaning it won't be showing anywhere else. So if you close the window, you don't need the Widget anywhere in your application anymore, or at least it's instance.

That's where std::unique_ptr<Widget> comes to claim hisits throne.


Update:

I don't really agree with @DominicMcDonnell, about the lifetime issue. Calling std::move on std::unique_ptr completely transfers the ownership, so even if you create an object A in a method and pass it to another object B as a dependency, the object B will now be responsible for the resource of object A and will correctly delete it, when object B goes out of scope.

I meant to write this as a comment, but it turned out to be too long.

How I know that Foobar is the only owner? In the old case it's simple. But the problem with DI, as I see it, is as it decouples class from construction of its dependencies, it also decouples it from ownership of those dependencies (as ownership is tied to construction). In garbage collected environments such as Java, that's not a problem. In C++, this is.

Whether you should use std::unique_ptr<Widget> or std::shared_ptr<Widget>, that is up to you to decide and comes from your functionality.

Let's assume you have a Utilities::Factory, which is responsible for the creation of your blocks, such as Foobar. Following the DI principle, you will need the Widget instance, to inject it using Foobar's constructor, meaning inside one of the Utilities::Factory's method, let's say createWidget(const std::vector<std::string>& params) const, you create the the Widget and inject it into the Foobar class.

Now you have a Utilities::Factory method, which created the the Widget object. Does it mean, the method should me responsible for it's deletion? Of course not. It is only there to make you the instance.


Let's imagine, you are developing an application, which will have multiple windows. Each window is represented using the Foobar class, so in fact the Foobar acts like a controller.

The controller will probably make use of some of your Widgets and you have to ask yourself:

If I go on this specific window in my application, I will need these Widgets. Are these widgets shared among other application windows? If so, I shouldn't probably be creating them all over again, because they will always look the same, because they are shared.

std::shared_ptr<Widget> is your friend.

You also have an application window, where there is a Widget specifically tied to this one window only, meaning it won't be showing anywhere else. So if you close the window, you don't need the Widget anywhere in your application anymore, or at least it's instance.

That's where std::unique_ptr<Widget> comes to claim his throne.


Update:

I don't really agree with @DominicMcDonnell, about the lifetime issue. Calling std::move on std::unique_ptr completely transfers the ownership, so even if you create an object A in a method and pass it to another object B as a dependency, the object B will now be responsible for the resource of object A and will correctly delete it, when object B goes out of scope.

I meant to write this as a comment, but it turned out to be too long.

How I know that Foobar is the only owner? In the old case it's simple. But the problem with DI, as I see it, is as it decouples class from construction of its dependencies, it also decouples it from ownership of those dependencies (as ownership is tied to construction). In garbage collected environments such as Java, that's not a problem. In C++, this is.

Whether you should use std::unique_ptr<Widget> or std::shared_ptr<Widget>, that is up to you to decide and comes from your functionality.

Let's assume you have a Utilities::Factory, which is responsible for the creation of your blocks, such as Foobar. Following the DI principle, you will need the Widget instance, to inject it using Foobar's constructor, meaning inside one of the Utilities::Factory's method, let's say createWidget(const std::vector<std::string>& params) const, you create the the Widget and inject it into the Foobar class.

Now you have a Utilities::Factory method, which created the the Widget object. Does it mean, the method should me responsible for it's deletion? Of course not. It is only there to make you the instance.


Let's imagine, you are developing an application, which will have multiple windows. Each window is represented using the Foobar class, so in fact the Foobar acts like a controller.

The controller will probably make use of some of your Widgets and you have to ask yourself:

If I go on this specific window in my application, I will need these Widgets. Are these widgets shared among other application windows? If so, I shouldn't probably be creating them all over again, because they will always look the same, because they are shared.

std::shared_ptr<Widget> is your friend.

You also have an application window, where there is a Widget specifically tied to this one window only, meaning it won't be showing anywhere else. So if you close the window, you don't need the Widget anywhere in your application anymore, or at least it's instance.

That's where std::unique_ptr<Widget> comes to claim its throne.


Update:

I don't really agree with @DominicMcDonnell, about the lifetime issue. Calling std::move on std::unique_ptr completely transfers the ownership, so even if you create an object A in a method and pass it to another object B as a dependency, the object B will now be responsible for the resource of object A and will correctly delete it, when object B goes out of scope.

1
source | link

I meant to write this as a comment, but it turned out to be too long.

How I know that Foobar is the only owner? In the old case it's simple. But the problem with DI, as I see it, is as it decouples class from construction of its dependencies, it also decouples it from ownership of those dependencies (as ownership is tied to construction). In garbage collected environments such as Java, that's not a problem. In C++, this is.

Whether you should use std::unique_ptr<Widget> or std::shared_ptr<Widget>, that is up to you to decide and comes from your functionality.

Let's assume you have a Utilities::Factory, which is responsible for the creation of your blocks, such as Foobar. Following the DI principle, you will need the Widget instance, to inject it using Foobar's constructor, meaning inside one of the Utilities::Factory's method, let's say createWidget(const std::vector<std::string>& params) const, you create the the Widget and inject it into the Foobar class.

Now you have a Utilities::Factory method, which created the the Widget object. Does it mean, the method should me responsible for it's deletion? Of course not. It is only there to make you the instance.


Let's imagine, you are developing an application, which will have multiple windows. Each window is represented using the Foobar class, so in fact the Foobar acts like a controller.

The controller will probably make use of some of your Widgets and you have to ask yourself:

If I go on this specific window in my application, I will need these Widgets. Are these widgets shared among other application windows? If so, I shouldn't probably be creating them all over again, because they will always look the same, because they are shared.

std::shared_ptr<Widget> is your friend.

You also have an application window, where there is a Widget specifically tied to this one window only, meaning it won't be showing anywhere else. So if you close the window, you don't need the Widget anywhere in your application anymore, or at least it's instance.

That's where std::unique_ptr<Widget> comes to claim his throne.


Update:

I don't really agree with @DominicMcDonnell, about the lifetime issue. Calling std::move on std::unique_ptr completely transfers the ownership, so even if you create an object A in a method and pass it to another object B as a dependency, the object B will now be responsible for the resource of object A and will correctly delete it, when object B goes out of scope.