Timeline for What are the benefits of dependency injection in cases where almost everyone needs access to a common data structure?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 23, 2015 at 12:08 | comment | added | Mike Nakis | @vsz of course, I was only exaggerating in order to make a point. Regarding the program which works on an image, either it can be considered as a much too small case to have any need to apply best practices on, or: this "program" should in fact consist of a tiny stub which simply loads the image, instantiates the library that will operate on the image, passes the image to the library, and finally saves the image. Essentially, the program would be wrapping the library into an executable. So, the library would still need dependency injection to obtain the image, to write to a log, etc. | |
| Sep 23, 2015 at 7:04 | comment | added | Eugene Ryabtsev | @gbjbaanb I believe the idea is to have one client class able to work exclusively on either ZorkA or ZorkB as pointed, not to have client class decide which of them to grab. | |
| Sep 23, 2015 at 4:30 | vote | accept | vsz | ||
| Sep 23, 2015 at 4:29 | comment | added | vsz | I didn't say everyone, I said almost everyone. The point of the question was whether DI has other benefits besides denying access from those few actors who don't need it. I know that "god objects" are an anti-pattern, but blindly following best practices can also be one. It can happen that the entire purpose of a program is to do various things with a certain resource, in that case almost everyone needs access to that resource. A good example would be a program which works on an image: almost everything in it has something to do with the image data. | |
| Sep 23, 2015 at 4:15 | vote | accept | vsz | ||
| Sep 23, 2015 at 4:30 | |||||
| Sep 22, 2015 at 14:49 | comment | added | gbjbaanb | Nope, I'm saying that if you need a ZorkA and a ZorkB you'll be instantiating them internally anyway and passing them to one client object or another. So you have a ZorkA and a ZorkB in your DI container. Without such a thing, you'll instantiate them both anyway and let the client object grab which one it needs. I don't mean they will be held as 2 global singletons. He is talking about service locators by the way he refers to with his idea about having a pointer to the global container. Its just turning DI on its head, which is a perfectly valid pattern. | |
| Sep 22, 2015 at 14:41 | comment | added | Mike Nakis | @gbjbaanb I do not suppose you are asking me to explain why it would be stupid to have two global instances of Zork, name them ZorkA and ZorkB, and hard-code into the objects which one will use ZorkA and which one will use ZorkB, right? | |
| Sep 22, 2015 at 14:40 | comment | added | Mike Nakis | @gbjbaanb Suppose that the resource is a Zork. The OP is saying that not only every single object in his system needs a Zork to work with, but also, that only one Zork will ever exist, and that all of his objects will only need access to that one instance of Zork. I am saying that neither of these two assumptions is reasonable: it is probably not true that all of his objects need a Zork, and there will be times when some of the objects will need a certain instance of Zork, while other objects will need a different instance of Zork. | |
| Sep 22, 2015 at 14:31 | history | edited | Mike Nakis | CC BY-SA 3.0 | added 181 characters in body |
| Sep 22, 2015 at 14:30 | comment | added | gbjbaanb | I'm not sure I understand this - on one hand you say DI allows you to use multiple instances of a resource and globals do not, which is plainly nonsense unless you're conflating a single static variable against multiply instantiated objects - there's no reason that "the global" must be either a single instance or a single class. | |
| Sep 22, 2015 at 14:06 | history | edited | Mike Nakis | CC BY-SA 3.0 | added 16 characters in body |
| Sep 22, 2015 at 14:01 | history | answered | Mike Nakis | CC BY-SA 3.0 |