Comments on: A simple explanation of dependency injection http://www.eviltester.com/index.php/2008/03/04/a-simple-explanation-of-dependency-injection/?utm_source=rss&utm_medium=rss&utm_campaign=a-simple-explanation-of-dependency-injection A different view of software testing Tue, 24 Jan 2012 20:03:46 +0000 hourly 1 http://wordpress.org/?v=3.1.3 By: Andy http://www.eviltester.com/index.php/2008/03/04/a-simple-explanation-of-dependency-injection/#comment-1410 Andy Tue, 16 Jun 2009 19:06:47 +0000 http://www.eviltester.com/index.php/2008/03/04/a-simple-explanation-of-dependency-injection/#comment-1410 Isn't the presentation simpler because it removes the considerations of larger systems. The presenter just says look at a framework and that "this is not a presentation on dependancy injection". The fowler paper is difficult to read if you don't know what DI is, it is meant to illustrate to define the difference between Inversion of Control, Dependancy Injection (of which there are subtypes) and Service Locator. It also begins to address the problem that you will find building a large system that dependents have dependents too. Using the example code above Database would have dependent of, say, some ability to build a connection. There presenter gives very questionable advice too: stop doing unit testing when you are up against a deadline seems to be one of them, and not the Abstract Factory? If DI is going to be used without a container it might be needed :) I mean the definition will be simpler if most of the details have been removed. The "real world" portion of the code, isn't. Isn’t the presentation simpler because it removes the considerations of larger systems. The presenter just says look at a framework and that “this is not a presentation on dependancy injection”. The fowler paper is difficult to read if you don’t know what DI is, it is meant to illustrate to define the difference between Inversion of Control, Dependancy Injection (of which there are subtypes) and Service Locator. It also begins to address the problem that you will find building a large system that dependents have dependents too. Using the example code above Database would have dependent of, say, some ability to build a connection. There presenter gives very questionable advice too: stop doing unit testing when you are up against a deadline seems to be one of them, and not the Abstract Factory? If DI is going to be used without a container it might be needed :)

I mean the definition will be simpler if most of the details have been removed. The “real world” portion of the code, isn’t.

]]>