> 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 (st

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