If you are using a good DI solution then the caller also has it's dependencies injected. If it needs an X to pass to the callee then it will have one injected (or it will have the means to create one injected [abstract factories are a good example]). If you extrapolate that out you end up with all of the decisions about *how to structure* your application in a layer by itself. This layer tends to be easier to implement using an IoC container but it doesn't need to be, you can roll it by hand if necessary.
That means that instead of "not knowing where the objects come from" you actually should only have one place to look. Note that the "loosely coupled units of work that can be reused easily" only occurs when all of your classes dependencies are abstractions. When your dependencies are abstractions the implementation of the actual (concrete) object you are talking to can vary independent of your class's implementation as long as the class you depend on adheres to the abstraction. This means you can reuse ANY of your classes in different contexts by reimplementing those abstractions that need to change for the new context. This context might be a test harness or it might be another part of your application or it might be another project entirely that requires the same business logic/algorithm. Having said all of that I know that selling it to a team that is not interested can be hard. If your app has any contact with any external systems (and they nearly all do) I'd introduce DI at those locations and use the excuse "it allows us to test OUR application without testing that external system" and then start to work your way back into the core. Start with "poor mans dependency injection" by For a given class: 1. Write/find abstractions for each of your dependencies 2. Change all variables that point to references of concrete dependencies in your class to use the abstractions 3. Shift the construction logic for those dependencies into the default constructor (this where you might need Func<> [which is an abstraction] to help you create factories or actually roll factory classes) 4. Create a 2nd constructor that accepts all of your abstract dependencies as parameters and use it for testing This prepares the class for DI in the future but isolates the change so that the rest of the app does not need to be modified. As each class that depends on this class is updated, use the constructor created in step 4 instead of the one in step 3. Eventually you will be able to delete the step 3 constructor. I feel I am rambling now so I'll leave it there :) Michael M. Minutillo Indiscriminate Information Sponge http://codermike.com On Thu, Oct 27, 2011 at 12:07 PM, <[email protected]> wrote: > ** > > Not wanting to start a flame war here, but DI has some dissenters: > > Black hat on : > > How can you say that dependency injection (I’m not taking on the whole > inversion of control pattern, but I might. Jury’s still out on that one.) > creates loosely coupled units that can be reused easily when the whole point > of DI is to require the caller to provide the callee’s needs? That’s an > increase in coupling by any reasonable assessment. Dumping the coupling > workload onto a framework doesn’t change the fact that it’s still a > requirement to supply external stuff to use an object. > > When you use DI as a ’Silver Bullet’ you are losing more then half the > abilities of your programming language. You can not use static methods or > the ‘new‘ keyword or sealed types. Oh, you have to make all your methods > virtual too. > > Black hat off. > > I use DI quite a lot, and it has a number of benefits but it is not a > magical solution. > > > > Rob > > On Thu, 27 Oct 2011 12:00:26 +0800, Nathan Schultz wrote: > > I'd probably sell it differently. > > Instead of saying you "don't know" where the objects come from, say that > objects come from a centrally configured location (since in practice the > objects are usually defined in configuration, or in bootstrap code). > > And sell cheaper maintenance costs (modular design, easy to refactor, easy > to replace components, easier to extend, fewer system wide bugs, helps with > a cleaner implementation, less spaghetti code, etc). > > To get it past some of the "old hats" here I temporarily changed > terminology. Dependency Injection (let alone IoC) would draw blank looks, > but say "plug-in system", and they've all rolled one before and are > comfortable with the concept. > > > > On Thu, Oct 27, 2011 at 11:56 AM, Stephen Price > <[email protected]>wrote: > >> Try not to think of it as right and wrong. Alt.net is a guide. It can >> help you find the path. >> >> On Thu, Oct 27, 2011 at 11:15 AM, Michael Ridland <[email protected]> >> wrote: >> > >> > So I've been working with this client for a few years now, all the other >> > developers aren't alt.net type. They're older and just love their RAD, >> User >> > Controls, coming from a dephi background. >> > It took me a while but finally I got them doing unit testing, but still >> not >> > as much as I would like. >> > Today I also tried to convince them(the development manager) to >> > use dependency injection but he said it was over complicating things and >> > it's confusing because you didn't know where the object came from. I >> argued >> > for decoupling and that objects shouldn't need to know >> > where dependences came from or how they were instantiated, objects >> should >> > only worry about their unit of work. >> > Am I wrong? >> > >> > >
