The term misleads by seeming to say that you are "injecting" a dependency. This would mean that the thing got the "dependency" injected into it now depends upon something that it didn't depend upon before. This is not what "dependency injection" means.
The term "dependency injection" actually means that if Object A depends upon having a "B" object that you "inject" a B object into object A (instead of object A fetching or creating a B on its own.) A classic example would be a Person object that depends upon having a database connection in order to create/update/edit/delete people in the database. Instead of the Person object creating its own database connection it gets one passed to it (i.e. "injected") perhaps as an argument to its constructor. But, see, you are not injecting a dependency. You are injecting a provider.
A "dependency" is not the thing upon which you depend. The thing you depend upon is a tool, resource, skill, or capability and you get those things by making them yourself, or from a provider.
So, I think the term "provider injection" should replace the term "dependency injection."
By the way, I want to thank Mike Ward for originally introducing me to the term "dependency injection" - whatever phrase is used, the actual practice is one I have done in the past and it is good to have a phrase to describe this technique.
See also:
Wikipedia entry on Dependency Injection (which I have attempted to edit.)
Inversion of Control Containers and the Dependency Injection pattern - 2004 article by Martin Fowler
Spring in Action - Book on Spring
Technorati Tags: inversion of control, software development
No comments:
Post a Comment