heh, in all the years I've seen DI (dating back to a Spring like world with beans via XML) i often see this type of argument spring up (hah, i worked that in beautifully). To me there is but one and only one reason you adopt DI.
"I'm freaking lazy" There is no separation really as either you take a "HAS-A" dependency upfront or you get it done later via a construct / method pass-in but either way you couple up to the interface at the very least (if not the concrete class itself). It still comes back to the whole "man, if only i had enough time to plan this through...i'd sure like it if i could have an IFoo class ri...oh it is...thank you Autofac..*kiss*..." :) --- Regards, Scott Barnes http://www.riagenic.com On Thu, Oct 27, 2011 at 2: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? >> > >> > >
