I’ve sucribed to Ayende Rabian RSS blog for a couple of months as he exposes very interesting ideas on programming best practices (I should add him in my blog roll). Recently an anthousiast discussion came out on DI (Dependency Injection). This debate was between Ayende and Jacob Profitt which are 2 smart and valuable guys. This kind of situation is not unusual when 2 smart and engaged folks have different opinions and whant to convice the other they are right. Both stay on their position even if they are open mind, and present valuable and interesting opinion.
IMHO, I think they are just both of them right but in a different context. There is no magic: everything in software development as a cost that you have to pay short term or medium and long term. You can’t use the same strategy if you are building a piece of code as a proptotype, or an open source framework.
Back to the topic of this post : DI benefits. If you wnat a simple and basic definition, go there. The main argument of Jacob is that DI is just useful for mocking…so testing. On the opposite, Ayende explain that DI is key to allow maintenability, testing and evolution. They are at least in agreement on the fact it helps to do testing. In fact they are in desagreement on the cost: if you don’t mind that much of mocking…do not use DI to avoid wast of time, it does not woth.
Separation of concern is key to me as I already write it in a previous post…but that depends on the context. If you are ther only dev on your project which is not used as a third aprty by other software, you less care about having code that can be understood by someone else (more over if this is a prototype or a software that will be used only once and then thhown away). But if the project involve a large team spread in different location that will have to evolve, or used as a framework by other teams that should be able to modify it…then DI really to make sence. I’ve no doubt on the fact DI provide a clear seperation of concern by relying on interfaces. The important key point is to use DI as it should: right granularity and level. I’ve worked recently on a project that should work on top of 2 web services exposed by 2 product of the company (…developped by 2 different teams). Using interfaces to get developers agreement on the interaction worked perfectly.
Obviously, using DI has a cost: it increase the size of the code (even if the code is more clear) …so the time to develop. If you also take this real opportunity to do TDD and hace a 100% test coverage, that increase the cost. What do you gain? First, having a 100% tested sofware provide strong evolution capabilities (you know what you break), but any change in requirement impact code and tests. Secondly, understandable code avoid bottlenecks and you can add ressoruces in your project at low cost and high efficiency.