Other developers don't like dependency injection
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?
RE: Other developers don't like dependency injection
No, you are not wrong. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Michael Ridland Sent: Thursday, 27 October 2011 13:46 To: ozDotNet Subject: Other developers don't like dependency injection So I've been working with this client for a few years now, all the other developers aren't alt.net<http://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?
Re: Other developers don't like dependency injection
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 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? >
Re: Other developers don't like dependency injection
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 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 > 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? > > >
Re: Other developers don't like dependency injection
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 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 wrote: >> > >> > So I've been working with this client for a few years now, all the other >> > developers aren't alt.net [2] 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? >> > Links: -- [1] mailto:rid...@gmail.com [2] http://alt.net [3] mailto:step...@littlevoices.com
Re: Other developers don't like dependency injection
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, 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 > 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 >> 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
Re: Other developers don't like dependency injection
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, 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 > 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 >> 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? >> > >> > >
Re: Other developers don't like dependency injection
On Thu, Oct 27, 2011 at 3:00 PM, 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. > > > Also, it sounds like those baddies, DLL Injection & SQL Injection. Make it sound different, and you could get a better reaction. -- Meski http://courteous.ly/aAOZcv "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
Re: Other developers don't like dependency injection
I don't buy the cheaper maintence costs argument, the 5 projects that I am supporting all use spring for DI. I spend half of my time trying to figure out how the damn thing is configured. Although a code based injector without xml config files at least alows you to debug the code and see what is missing. I like DI, but it sure doesn't save time. Davy "When all you have is a hammer, every problem looks like a nail." I feel much the same way about xml -Original Message- From: mike smith Sender: ozdotnet-boun...@ozdotnet.com Date: Thu, 27 Oct 2011 16:46:45 To: ozDotNet Reply-To: ozDotNet Subject: Re: Other developers don't like dependency injection On Thu, Oct 27, 2011 at 3:00 PM, 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. > > > Also, it sounds like those baddies, DLL Injection & SQL Injection. Make it sound different, and you could get a better reaction. -- Meski http://courteous.ly/aAOZcv "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
Re: Other developers don't like dependency injection
#1 I am a fan of DI and agree about the hard way of selling it. My reasoning for DI is tests. *Tests help us to prevent regression, clarify requirements with clients (BDD) and act as documentation. In order to write some tests we need to inject a dummy. How do we inject a dummy? --> DI* #2 I am not a big fan of IoC containers either. I have similar experiences as Justin documented here (although the setup of dependencies can become messy without IoCC) http://codelikebozo.com/breaking-up-with-ioc .peter.gfader. (current mood = happy) http://blog.gfader.com On Thu, Oct 27, 2011 at 10:05 AM, wrote: > ** I don't buy the cheaper maintence costs argument, the 5 projects that > I am supporting all use spring for DI. > I spend half of my time trying to figure out how the damn thing is > configured. > > Although a code based injector without xml config files at least alows you > to debug the code and see what is missing. > > I like DI, but it sure doesn't save time. > > Davy > > "When all you have is a hammer, every problem looks like a nail." I feel > much the same way about xml > -- > *From: * mike smith > *Sender: * ozdotnet-boun...@ozdotnet.com > *Date: *Thu, 27 Oct 2011 16:46:45 +1100 > *To: *ozDotNet > *ReplyTo: * ozDotNet > *Subject: *Re: Other developers don't like dependency injection > > On Thu, Oct 27, 2011 at 3:00 PM, 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. >> >> >> > Also, it sounds like those baddies, DLL Injection & SQL Injection. Make > it sound different, and you could get a better reaction. > > > -- > Meski > >http://courteous.ly/aAOZcv > > "Going to Starbucks for coffee is like going to prison for sex. Sure, > you'll get it, but it's going to be rough" - Adam Hills > > -- .peter.gfader. Current mood = happy! Check this before you go live http://blog.gfader.com/2011/07/website-check-list-part-1-aspnet-4.html
Re: Other developers don't like dependency injection
As others have said try selling it differently...but don't expect miracles because that's what's needed with some developers. I've run into a few. If there is true benefit to DI in your project(s) then push for it but don't get too upset if you don't get your way. I'm curious though, how is unit testing happening without at least some DI? Or are only parts of the system being unit tested and the rest ignored? On Thu, Oct 27, 2011 at 2:15 PM, Michael Ridland 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? >
Re: Other developers don't like dependency injection
I'm actually wishy washy with DI as well, at first I was pretty damn excited with it, but I suppose it depends on the circumstance and use case. If you're at work and you're pressed on time and budget, you'd need to do some big convincing to show the future benefits. Furthermore like everyone has said, to sell a feature or a toolset, you really need to nail it at a different perspective, rather than saying DI is awesome, I've used it, it's great for decoupling. Like if you drop subtle problems in the design/architecture of the system that DI can solve, it might communicate your point in a more applicable way. On Thu, Oct 27, 2011 at 7:53 PM, DotNet Dude wrote: > As others have said try selling it differently...but don't expect > miracles because that's what's needed with some developers. I've run > into a few. If there is true benefit to DI in your project(s) then > push for it but don't get too upset if you don't get your way. > > I'm curious though, how is unit testing happening without at least > some DI? Or are only parts of the system being unit tested and the > rest ignored? > > > On Thu, Oct 27, 2011 at 2:15 PM, Michael Ridland 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? > > >
