User badlife says this:
DI is a lot deeper than you’re thinking. It’s an entirely different way of doing architecture. Here’s a simple example:
- I’m a component. I need X to do some work. So I’ll create an instance of X and use it. I don’t want Y, or something that looks like X but behaves differently– I want an instance of X and only X.
- I’m a component. I need an instance of X to do some work
- I’m not going to create an instance of X– I’ll let you give me one when you create me
- I don’t care if X is really X, as long as it looks like X.
- I don’t want Y, but if Y pretends to be X, I’ll never know. This is because I only want something that lookslike X.
Here’s an example in concrete terms:
- The ‘component’ is something that does a calculation. As part of the calculation, it needs to call a web service to get a value (let’s say an interest rate)
- X is usually a component that calls a web service to get the interest rate
- Y is a testing component that just returns ‘1.0’ for the interest rate
Without DI, the component is very hard to test because it needs to call a ‘live’ web service to get an interest rate. What if that web service isn’t live? What if it isn’t accessible from the testing environment? The test could be running as part of a build, and the build server might not be able to see the web service.
With DI, both X and Y can implement a common interface. The component doesn’t actually create an instance of X– it just asks for a reference to the interface. So in a real world scenario, the system gives the component a ‘real’ instance of X by passing a reference to its interface. In a testing scenario, the system gives the component a ‘fake’ version of X (it’s actually Y!) also by passing a reference to its interface. The component doesn’t know or care about the internal implementation of what it thinks is X, and can do its work without the web service being available.