4 ms·

Worst offender for me is when I can't access the implementation by just clicking on the type or variable, because it is an interface. For example with dependen

by hu3 3y ago

Worst offender for me is when I can't access the implementation by just clicking on the type or variable, because it is an interface. For example with dependency injection in languages where devs put Interfaces in constructors and some magic injects the Class that satisfies that Interface at runtime. When you click the type or variable, the IDE opens the Interface file which is just a bunch of function signatures, no implementation. It's infuriating when all you want is to see some concrete code. You just want to see exactly what code is being executed and then carry on with your day. I get the benefits of dependency injection but most of the times a single class implements that interface and yet i'm forced to scavenge the code to find it. I also know some tooling is powerful enough to list the Classes that satisfy that Interface. But it's not perfect and it's still a layer of indirection adding to my cognitive load.

andix 3y ago
My IDE (Jetbrains) has a „jump to implementation“ feature. If there is just one class implementing the interface it just jumps there. If there are multiple you get a drop down.
LeonB 3y ago
I agree. In Visual Studio I’ve gotten used to using “Ctrl F12” to go to “implementation” instead of F12 for go to definition. If there’s only one implementation it takes you straight to it, and if there’s multiple it lists them so you can pick one.
vsareto 3y ago
Visual Studio has “Go To Definition” and “Go To Implementation” - the first will take you to the interface, the second will take you to the class that implements the interface (or show results for multiple implementations if those exist). I would try to find that functionality in your tools because it makes a world of difference.
briHass 3y ago
This is one of the nice things about Visual Studio: F12 jumps to the declaration (the interface) and Ctrl-F12 jumps to the implementation (the service) or presents a chooser if there are multiple implementors. I find that shortcut easy/powerful enough that it's no additional burden on my cognitive load. At least, it's no more taxing than inversion of control is generally.
_gabe_ 3y ago
> I get the benefits of dependency injection I don't. I think dependency injection encourages thoughtless code. It makes it easier to "magically" make your dependencies appear wherever you want them without having to think about anything except the lifetime. Once you're project gets significantly complex, it becomes very difficult to understand what your web of dependencies is actually doing, and to comprehend how the lifetimes all interact. Screw dependency injection. Do it the "hard way" and make the pain points ridiculously clear so that you can see where the flaws in your architecture are revealing themselves.
- aakresearch 3y ago
  I am with you. The analogy I came up with is "map layers". Usually on a geographical map the features are drawn using contours, colours and accompanying names. Such map is, certainly, not a "territory" but is a good representation and easy to work with. Using (capital DI!) Dependency Injection is like a having a map "lobotomized", split into layers where you can never see them together. You either see contours devoid of names, or names hanging in the void. Bonus point if names don't even follow the contours. For any non-trivial number of classes/concepts my brain explodes. Another bonus point when DI is used for some deep-context "dependencies". Hey, I need a HttpClient object here, to post something somewhere. Why, instead of having a URL and instantiating my client right here, I need to dig through the sands of DI bindings to find a way to "configure" HttpClient for this particular instance? Well, I understand theoretical reasons, but in practice they never make sense and only add pain. Another bonus point for run-time binding errors. Those sometimes slip through even when there is a "test" in the CI/CD suite for that. I think dependency injection has its place, but as used presently it resembles a cargo-cult.

by hu3 3y ago

andix 3y ago

My IDE (Jetbrains) has a „jump to implementation“ feature. If there is just one class implementing the interface it just jumps there. If there are multiple you get a drop down.

LeonB 3y ago

I agree. In Visual Studio I’ve gotten used to using “Ctrl F12” to go to “implementation” instead of F12 for go to definition. If there’s only one implementation it takes you straight to it, and if there’s multiple it lists them so you can pick one.

vsareto 3y ago

Visual Studio has “Go To Definition” and “Go To Implementation” - the first will take you to the interface, the second will take you to the class that implements the interface (or show results for multiple implementations if those exist). I would try to find that functionality in your tools because it makes a world of difference.

briHass 3y ago

This is one of the nice things about Visual Studio: F12 jumps to the declaration (the interface) and Ctrl-F12 jumps to the implementation (the service) or presents a chooser if there are multiple implementors. I find that shortcut easy/powerful enough that it's no additional burden on my cognitive load. At least, it's no more taxing than inversion of control is generally.

_gabe_ 3y ago

> I get the benefits of dependency injection I don't. I think dependency injection encourages thoughtless code. It makes it easier to "magically" make your dependencies appear wherever you want them without having to think about anything except the lifetime. Once you're project gets significantly complex, it becomes very difficult to understand what your web of dependencies is actually doing, and to comprehend how the lifetimes all interact. Screw dependency injection. Do it the "hard way" and make the pain points ridiculously clear so that you can see where the flaws in your architecture are revealing themselves.

aakresearch 3y ago
I am with you. The analogy I came up with is "map layers". Usually on a geographical map the features are drawn using contours, colours and accompanying names. Such map is, certainly, not a "territory" but is a good representation and easy to work with. Using (capital DI!) Dependency Injection is like a having a map "lobotomized", split into layers where you can never see them together. You either see contours devoid of names, or names hanging in the void. Bonus point if names don't even follow the contours. For any non-trivial number of classes/concepts my brain explodes. Another bonus point when DI is used for some deep-context "dependencies". Hey, I need a HttpClient object here, to post something somewhere. Why, instead of having a URL and instantiating my client right here, I need to dig through the sands of DI bindings to find a way to "configure" HttpClient for this particular instance? Well, I understand theoretical reasons, but in practice they never make sense and only add pain. Another bonus point for run-time binding errors. Those sometimes slip through even when there is a "test" in the CI/CD suite for that. I think dependency injection has its place, but as used presently it resembles a cargo-cult.