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