4 ms·

I find passing dependencies via constructor arguments make codebases a lot easier to navigate: it encourages a pattern where you have a single file that wires u

I find passing dependencies via constructor arguments make codebases a lot easier to navigate: it encourages a pattern where you have a single file that wires up the entire system and you can look at that file to get a sense of which modules are talking to which other modules. Gilad Bracha had some interesting posts that talk about this pattern: https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1 https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1

colanderman 5y ago
I find that pattern makes navigation harder, particularly in untyped languages: because the particular implementation is now no longer statically resolvable, now I have to walk up a call tree to find which implementation (or even, which type, in an untyped language) corresponds to each of those constructor arguments, rather than just looking at the top of the file.
- fiddlerwoaroof 5y ago
  I think this indicates bad modularity in the codebase and/or badly specified interface contracts. I’ve found that this makes finding bugs easier because I can start in the wiring file and then drill down to the only code that handles stuff relevant to the bug: by giving one place that lays out the high-level structure of a codebase, that place becomes like the “table of contents” for the rest of the code. This particular benefit is almost completely destroyed by DI frameworks that use annotations and other magic to automatically wire together a codebase. So, I just don’t use those.
EdwardDiego 5y ago
Constructor args are the simplest form of dependency injection :) And when I'm using a DI framework, the only injection point I'm happy with. But, having worked on a large codebase that used constructors with no DI framework, it makes adding a new dependency used in multiple bottom nodes of the graph very painful.
wonnage 5y ago
It’s super painful to figure out where this magically injected dependency came from. Now you have to look at every place that the object was constructed. And god forbid those constructors also use injected dependencies. I hate Guice.
- fiddlerwoaroof 5y ago
  The solution here is not to use something like Guice and to only call the constructor once.

colanderman 5y ago

I find that pattern makes navigation harder, particularly in untyped languages: because the particular implementation is now no longer statically resolvable, now I have to walk up a call tree to find which implementation (or even, which type, in an untyped language) corresponds to each of those constructor arguments, rather than just looking at the top of the file.

fiddlerwoaroof 5y ago
I think this indicates bad modularity in the codebase and/or badly specified interface contracts. I’ve found that this makes finding bugs easier because I can start in the wiring file and then drill down to the only code that handles stuff relevant to the bug: by giving one place that lays out the high-level structure of a codebase, that place becomes like the “table of contents” for the rest of the code. This particular benefit is almost completely destroyed by DI frameworks that use annotations and other magic to automatically wire together a codebase. So, I just don’t use those.

EdwardDiego 5y ago

Constructor args are the simplest form of dependency injection :) And when I'm using a DI framework, the only injection point I'm happy with. But, having worked on a large codebase that used constructors with no DI framework, it makes adding a new dependency used in multiple bottom nodes of the graph very painful.

wonnage 5y ago

It’s super painful to figure out where this magically injected dependency came from. Now you have to look at every place that the object was constructed. And god forbid those constructors also use injected dependencies. I hate Guice.

fiddlerwoaroof 5y ago
The solution here is not to use something like Guice and to only call the constructor once.