Hacker News Reader

Comment by itronitron | Hacker News Reader

while I agree with you I think it is also common for authors of articles on design patterns to talk up the design pattern as something new, and give it a horribly abstract name like 'dependency injection' instead of something common and specific that people otherwise familiar with the pattern can easily map their experience to. In the case of 'dependency injection' which to the best of my knowledge is just 'passing in data to the constructor' this may have been a new concept for the people that came up with it, or it may have been a rebranding effort.

View on HN

Dependency injection is a very specific way of passing in data to the constructor. In fact, those specifics are one of the important lessons of dependency injection; it makes a big difference whether your constructor accepts parameters for a database connection or a database connection itself.

If a design pattern is new, then it isn't a design pattern -- by definition :-). I neglected to say it outright, but a design pattern is a solution to a problem that already exists in code bases within different domains. The recommended number of different domains is 3 (which is why I used that in my example). The pattern is there to document the situation where the solution applies, where it doesn't apply (very important!), and to give a name to it. Some of the common names for design patterns are arguable pretty poor, although I've never actually seen dependency injected written up as a design pattern (it definitely could be).

I could go on for quite a while about specifics of design patterns (and particularly "generative design patterns" and "pattern languages"), but I think I would be accused of writing an article about design patterns ;-). I think the biggest problem I've seen with articles on design patterns is that there are a lot of articles that are written by people who don't understand them, and haven't read the original literature about them. This isn't confined to design patterns, though. I could say the same thing about pretty much everything in our industry. If you find an article saying x-famous-thing-is-crap, you can almost be positive that if you go back to the origins of x-famous-thing that it's not actually crap at all -- it's just been badly misunderstood by successive generations of anti-evangelists.

> In the case of 'dependency injection' which to the best of my knowledge is just 'passing in data to the constructor'

Not quite, it's passing dependencies (structural ones, like a logger or a database connection) to the constructor. If you're passing data in via a dependency injector then something has gone terribly wrong. Before dependency injection was common creating these dependencies was typically handled by either a factory or created inline, the biggest issues this create was difficulty to test and difficulty to scope. DI handles these well, at the cost of reflection magic and occasionally harder traceability.

So yes, I've drunk the cool aid on DI. Lately however I've been getting back into c which obviously lacks a lot of features conducive to unit testing and DI which, but so far I've been able to get similar results from a few macros. So while I still like/use DI when I'm working with c#, I think we've gone wrong at some level, we should be able to write tests without adding so much indirection everywhere.

What's a less abstract name for dependency injection?

Better boilerplate code constructing things.

That's not a name and it's not a good name. Naming is hard: you need a succint yet descriptive and specific phrase. "Dependency injection" nicely evokes the issue of your code depending on other code and how you can avoid hardcoding dependencies by injecting a reference to them at start of execution.

Constructors With Arguments would be my suggestion

The main point of dependency injection isn't that you're passing collaborators into the constructor though -- that's just an implementation detail.

It's about achieving inversion of control, and using a constructor to inject dependencies is just one example of how to do that. There's also setter based DI, and interface based injection, but again, those are just implementation details.

Reply on news.ycombinator.com