Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


Magical 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.


We'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).




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: