4 ms·
This also applies to dependency injection. While it has significant benefits, it hurts clarity of the code. It becomes more difficult to see where each object i
by eterevsky 2y ago
This also applies to dependency injection. While it has significant benefits, it hurts clarity of the code. It becomes more difficult to see where each object is coming from.
- mrkeen 2y agoMagical dependency injection frameworks, that is. Plain old putting-dependencies-in-the-constructor-instead-of-newing-them is great. If you 'wire' it yourself, you see the top-level structure of the project in main, e.g. cache <- createCache "./cache" workQueue <- createWorkQueue parallelism projectFinder <- createProjectFinder basePath gradleBuilder <- createGradleBuilder cache normaliser <- createNormaliser gradleParser <- createGradleParser normaliser relationFinder <- createRelationFinder cache normaliser At a glance I can see what uses normaliser, and what is used by normaliser.
- kgeist 2y agoWe've ditched "magical dependency injection frameworks" for manual injections in constructors and the net result is that development is actually faster. Yes, you write slightly more code, but at the same time, it's much easier to figure out what's going on. Before, if something went wrong, we would get some arcane errors from deep inside the DI framework and had to decypher what it means and what changes we need to apply to the configs. Now, it's just regular code (great with refactorings and greppability, too).