Timeline for Why is Dependency Injection called "alternative of global state"?I think global state still exists
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 10, 2023 at 6:55 | comment | added | Ben Cottrell | @Steve No, as I said above, my comments have nothing to do with control over the objects themselves (neither their state nor their lifetime), it is about control over scope and the implication that has for coupling. You seem to be focused on lifetime and mutation of object state but as I mentioned above, DI is not about state. I am not making any guarantees about control over the dependencies themselves as that is an entirely separate issue to coupling and scope. Nowhere in any of my comments have I made any claims nor guarantees about DI controlling state or lifetime of dependencies. | |
| Jul 9, 2023 at 16:04 | comment | added | Steve | The discipline of how DI is used carries all the weight - which was exactly the problem with global variables, that too many lacked enough discipline! So my point, to be clear, is that you're overselling the guarantees of DI and fabricating false contrasts. Both allow external control of the dependency. Neither ensures anything by default. Both demand a large dose of discipline to use correctly, and inflict the same risks and errors when that discipline is lacking (2/2) | |
| Jul 9, 2023 at 16:03 | comment | added | Steve | @BenCottrell, but if you store an object in a global variable, and then point to that variable from another class, the dependency between that class and that global object is also controlled from outside.and not inside - via the setting of a global variable instead of the supply of a parameter. And we've already established that the object to which the class refers doesn't need to be "explicitly" supplied - only a path to the object needs to be supplied. DI really doesn't "ensure" much by default. (1/2) | |
| Jul 9, 2023 at 15:25 | comment | added | Ben Cottrell | Obviously when it comes to programmers directly controlling it themselves, it depends on the implementation (and typically there is an IoC container), but as always, any technique or pattern can be open to misuse if implemented poorly or used for the wrong reasons, but that's an entirely separate issue, creeping into the kind of opinionated/subjective territory about "best practice" and "right/wrong ways" which this site generally tries to avoid | |
| Jul 9, 2023 at 15:21 | comment | added | Ben Cottrell | @Steve That part of my comment is not about programmers themselves being controlled or disciplined, nor is it about whether the code is better or worse as a result; it is about the fact that DI is inversion of control with regards to scope; controlled from the outside rather than the inside (Which is how access to globals would happen). My point is that DI ensures that any class or method which needs access to an object must be given that object explicitly from the outside for that object to be within its scope, because otherwise it has no way of knowing where to find it. | |
| Jul 8, 2023 at 8:10 | comment | added | Steve | The corollary is that for those who do have the discipline to use DI to control access to shared variables, you could often just use globals and have cleaner, simpler code than you'd have with DI. The first thing the undisciplined will do with DI code they didn't write but need to add to, is hack in a globally-accessible path to the variables they want to share across scopes. (2/2) | |
| Jul 8, 2023 at 8:08 | comment | added | Steve | @BenCottrell, we're not at odds, but I picked up on the point that "you must explicitly pass the object into...". It's actually far weaker than this - only a path to the object need be passed (assuming that objects can have references to one another). There's potentially a considerable amount of extra discipline (and design complexity) necessary to ensure access to those paths remains under control. The consequence is that for those who would use globals with no discipline, they will use DI with just as little discipline - so more complexity than using globals, but no more control. (1/2) | |
| Jul 8, 2023 at 7:33 | comment | added | Ben Cottrell | @Steve I'm not sure how that relates to my comment, which is about controlling scope and the direction of dependency, it's not about control over the state of an object, as control over state really has nothing to do with dependency injection. | |
| Jul 7, 2023 at 22:21 | comment | added | Filip Milovanović | I think what mislead you is the way the question is phrased in the linked page. The person who asked was inquiring about alternatives to a design based on having globally accessible state. And alternative was pointed out that uses Dependency Injection (DI), which is fine, but DI is not specifically about managing state. DI is not about taking that state as a whole and passing it everywhere, and in fact, how state is managed and distributed throughout different classes is not even the primary concern of DI as a design technique. | |
| Jul 7, 2023 at 17:13 | answer | added | DavidT | timeline score: 0 | |
| Jul 7, 2023 at 16:33 | answer | added | candied_orange | timeline score: 0 | |
| Jul 7, 2023 at 14:15 | comment | added | Alexander | "Because I think "clickCount" state still exists in the memory of computer at the life time of the app running" That's not a useful definition of global state. At the extreme, in a language that lets you use pointer arithmetic to access values at any arbitrary address, then literally all values end up as this definition of "global state" (even local variables and function parameters, which are accessible from the stack!) | |
| Jul 7, 2023 at 12:09 | answer | added | Steve | timeline score: 4 | |
| Jul 7, 2023 at 11:47 | comment | added | Steve | @BenCottrell, I think a crucial subtlety is that DI only enables some additional control, it doesn't actually enforce additional control. You don't need to pass the shared object itself into the contexts which use it - you only need to inject something capable of getting a reference to the shared object. | |
| Jul 7, 2023 at 10:33 | review | Close votes | |||
| Jul 12, 2023 at 3:07 | |||||
| Jul 7, 2023 at 10:15 | comment | added | Ben Cottrell | In short, it has nothing to do with whether the dependency is stateful, it's about maintaining control over that dependency and its accessibility. (Dependency injection is "inversion-of-control" so the dependency direction is controlled from the outside) | |
| Jul 7, 2023 at 10:09 | comment | added | Ben Cottrell | "Global" means "exists in the program's global scope" -- the object from the second example is not in the program's global scope, it is created within the scope of the main method and then passed down into the scope of a Page1 instance; that means its scope is fully under your control. (I.e. you must explicitly pass the object into any function or class which needs to access it, which keeps it constrained and keeps the program's dependency graph under explicit control). On the other hand, there is no such control for methods or classes which depend upon global scoped objects. | |
| Jul 7, 2023 at 10:04 | history | asked | wcminipgasker2023 | CC BY-SA 4.0 |