Timeline for Criticism and disadvantages of dependency injection
Current License: CC BY-SA 4.0
31 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 12, 2018 at 15:38 | comment | added | user2023861 | Criticism ... of dependency injection Sometimes when I have all of these small classes, I have trouble seeing the bigger picture. That is, I have trouble seeing the forest for the trees. I have to step back and ask myself, "What is it I actually want to accomplish". I wonder if over devs experiences this. | |
| Jun 8, 2018 at 5:03 | history | tweeted | twitter.com/StackSoftEng/status/1004951911898992640 | ||
| Jun 3, 2018 at 19:15 | answer | added | Vilx- | timeline score: 27 | |
| Jun 1, 2018 at 13:50 | comment | added | T. Sar | The DI is almost always good. The bad thing with it is a lot of people think they know DI but all they know is how to use some weird framework without even being sure of what they are doing. DI nowadays suffers a lot from Cargo Cult Programming. | |
| Jun 1, 2018 at 9:16 | answer | added | maaartinus | timeline score: 6 | |
| May 30, 2018 at 18:35 | comment | added | Reactgular | I can hardly remember my life before DI, but it involved a lot of "search for new MyClass() and replace every occurrence with new MyClass(x,y)" until I got tired of trying to figure out which x and which y to pass from points in the source code that didn't care about those things. | |
| May 30, 2018 at 12:09 | comment | added | usr | I often write tests using the real database and no mock objects at all. Works really well in many cases. And then you don't need interfaces most of the time. If you have a UserService that class is just a holder for logic. It gets injected a database connection and tests run inside of a transaction that is rolled back. Many would call this bad practice but I found that this works extremely well. Don't need to contort your code just for testing and you get the bug finding power of integration tests. | |
| S May 30, 2018 at 12:03 | history | suggested | Peter Mortensen | CC BY-SA 4.0 | Copy edited. Added some context. |
| May 30, 2018 at 11:32 | history | protected | gnat | ||
| May 30, 2018 at 6:29 | comment | added | Logan Pickup | I agree with jpmc26 - everything you list as an advantage (and the disadvantages, too!) is actually an advantage of dependency inversion, not injection. It's just that injection often forces you to use dependency inversion as well. | |
| May 30, 2018 at 3:43 | answer | added | Rodney P. Barbati | timeline score: 8 | |
| May 29, 2018 at 23:32 | review | Suggested edits | |||
| S May 30, 2018 at 12:03 | |||||
| May 29, 2018 at 22:41 | comment | added | Frank Hileman | Your list of "pros" is incorrect. There is nothing "good" about adding dependency injection where it is not needed. | |
| May 29, 2018 at 21:44 | answer | added | Eric | timeline score: 68 | |
| May 29, 2018 at 15:40 | vote | accept | Arkadiusz Kałkus | ||
| May 29, 2018 at 15:08 | history | edited | Robert Harvey | CC BY-SA 4.0 | deleted 15 characters in body |
| May 29, 2018 at 14:59 | comment | added | Robert Harvey | CQRS doesn't have anything to do with the repository pattern, other than they are used in the same place in the architecture. It sounds like you're inexperienced. Folks who lack experience tend to work with patterns too early, before they are ready. The remedy is not to learn more patterns (especially from blog posts), it is to get better at software development overall. Wax on, wax off. | |
| S May 29, 2018 at 14:49 | history | suggested | Matteo Italia | CC BY-SA 4.0 | Typo, formatting |
| May 29, 2018 at 14:43 | review | Suggested edits | |||
| S May 29, 2018 at 14:49 | |||||
| May 29, 2018 at 14:43 | comment | added | Arkadiusz Kałkus | @Honey I'm asking about disadvantages, not scenarios when not to use. You can use something even if it has disadvantages as long as they are minor compared to advantages. But understanding them is valuable to become better engineer. | |
| May 29, 2018 at 14:34 | comment | added | Honey | Possible duplicate of When is it not appropriate to use the dependency injection pattern? | |
| May 29, 2018 at 14:25 | comment | added | Arkadiusz Kałkus | @jpmc26 Well, I said pattern, not principle. I think it's reasonable to call DI a pattern. Anyway I know that DI != IoC/DInv, but thanks to mentioning the important issue. | |
| May 29, 2018 at 14:16 | comment | added | jpmc26 | You're confusing dependency inversion with dependency injection. The former is a design principle. The latter is a technique (usually implemented with an existing tool) for constructing hierarchies of objects. | |
| May 29, 2018 at 14:03 | comment | added | Arkadiusz Kałkus | @Frax about pattern, not frameworks | |
| May 29, 2018 at 13:34 | answer | added | JacquesB | timeline score: 124 | |
| May 29, 2018 at 13:03 | answer | added | Berin Loritsch | timeline score: 214 | |
| May 29, 2018 at 12:26 | comment | added | Frax | Are you really asking about depenency injection as a pattern, or are you asking about using DI frameworks? These are really distinct things, you should clarify which part of problem you are interested in, or explicitly ask about both. | |
| May 29, 2018 at 12:01 | review | Close votes | |||
| Jun 8, 2018 at 3:02 | |||||
| May 29, 2018 at 11:38 | answer | added | Rob | timeline score: 26 | |
| May 29, 2018 at 11:36 | answer | added | Ewan | timeline score: -4 | |
| May 29, 2018 at 11:20 | history | asked | Arkadiusz Kałkus | CC BY-SA 4.0 |