Question

I understand dependency injection, but have not had that “ah” moment, where it clicks and I really see the light.

Why should I use DI? Also, when mocking objects like those which use the file system, what would the mock object be capable of? Does it just do dummy calls (so does not really use the file system)?

Answer 1

Let me go a couple steps farther from hvgotcodes answer:

class Service {
   Collaborator c = new Collaborator()
}

is your original class with the hard-coded dependency.

class Service {
    Collaborator c;

    Service(Collaborator c) {
       this.c = c;
    }
}

is your newfangled class with the injected dependency.

So far, so good. Now, let’s take Collaborator and extract an interface from it; call it ICollaborator. Now your newerfangled class looks like such:

class Service {
    ICollaborator c;

    Service(ICollaborator c) {
       this.c = c;
    }
}

What does this buy you? Well, you can, in your code, create this class to behave like the first example as such:

// w00t!  My code compiles and works again!  Ship it!
Service myService = new Service(new Collaborator());

Pretty cut and dry easy. The beauty comes from when you want to use a different type of Collaborator — perhaps even a mock or fake. So long as it implements the ICollaborator interface, you’re golden:

// I'm using Fake It Easy for this example.
Service myService = new Service(A.Fake<ICollaborator>());

Voila! You now have a unit-testable Service instance that doesn’t drag the concrete Collaborator along for the ride (which would be breaking true “unit” testing).