Dependency injection and IoC containers are a fact of life that I've lived with for several years now. Its pretty much a given that any new project will start out with a bunch of fancy plumbing to allow for dependency injection.
I'm aware that SOLID principles dictate an inversion of control and dependency injection is a way to achieve that. After a few years of use however, I have begun to seriously question the usefulness of this pattern.
Perhaps I simply have a fundamental understanding which is preventing me from seeing the benefits of DI; hence this thread.
Yes being able to switch between TST and PRD versions of your classes at the flick of a switch is awesome. Now tell me when the last time your PM included time in your delivery schedule to maintain two versions of your classes. And if they did, how long before your TST & PRD versions were out of sync and effectively useless?
I totally get how coding by contract is a useful tool. What I don't understand is the fixation on using DI and IoC for every single project. Please help me understand...
I'm aware that SOLID principles dictate an inversion of control and dependency injection is a way to achieve that. After a few years of use however, I have begun to seriously question the usefulness of this pattern.
Perhaps I simply have a fundamental understanding which is preventing me from seeing the benefits of DI; hence this thread.
Yes being able to switch between TST and PRD versions of your classes at the flick of a switch is awesome. Now tell me when the last time your PM included time in your delivery schedule to maintain two versions of your classes. And if they did, how long before your TST & PRD versions were out of sync and effectively useless?
I totally get how coding by contract is a useful tool. What I don't understand is the fixation on using DI and IoC for every single project. Please help me understand...
via International Skeptics Forum http://ift.tt/1vP5Ynz
Aucun commentaire:
Enregistrer un commentaire