Spring In Context: Core Concepts

The first reference to what would eventually become Dependency Injection appeared in 1994 in a paper by Robert C. Martin called “The Dependency Inversion Principle”.

In “The Dependency Inversion Principle” (or DIP), the author states the three defining factors of “bad code”:

According to Martin, interdependency causes these coding problems (we'll call them RFI for Rigidity, Fragility, and Immobility). To fix RFI issues in your OO code, DIP has two basic rules:

1. High level modules should not depend upon low level modules, both should depend upon abstractions.

In other words, high level modules – which contain your business logic and all of the important meat of your application – should not depend on lower level components. The reason for this is if these lower level components were to change, the changes might affect the higher level components as well. This is the defining concept behind dependency inversion, that the prevailing wisdom of having higher-level modules dependent on lower-level modules is in fact a bad idea.

2. Abstractions should not depend upon details, details should depend upon abstractions.

This is another way to say that before you begin coding to the abstraction – the interface or abstract class -- you should find the common behaviors in the code and work backwards. Your interface /abstraction should cater to the intersection between the needs of your business logic and the common behaviors of the lower level modules. You should also leave the details of how these behaviors are implemented to the implementation classes.

This simple example of a voting booth program shows a non-DIP compliant program.

                    
package org.springbyexample.vote;

public class VotingBooth {

    VoteRecorder voteRecorder = new VoteRecorder();
    
    public void vote(Candidate candidate) {
        voteRecorder.record(candidate);
    }
    
    class VoteRecorder {
        Map hVotes = new HashMap();
        
        public void record(Candidate candidate) {
            int count = 0;
            
            if (!hVotes.containsKey(candidate)){
                hVotes.put(candidate, count);
            } else {
                count = hVotes.get(candidate);
            }
            
            count++; 
            
            hVotes.put(candidate, count);  
            
        }
    }

}
                    
                

	This increments the count variable.
	Add candidate and votes to Map.

In this example, the VotingBooth class is directly dependent on VoteRecorder, which has no abstractions and is the implementing class.

A dependency “inverted” version of this code might look a little different. First, we would define our VoteRecorder interface.

                    
package org.springbyexample.vote;

public interface VoteRecorder {

    public void record(Candidate candidate) ;

}
                    
                

And our implementing classes.

The LocalVoteRecorder, which implements the VoteRecorder interface:

                    
package org.springbyexample.vote;

public class LocalVoteRecorder implements VoteRecorder {

    Map hVotes = new HashMap();
    
    public void record(Candidate candidate) {
        int count = 0;
        
        if (!hVotes.containsKey(candidate)){
            hVotes.put(candidate, count);
        } else {
            count = hVotes.get(candidate);
        }
        
        count++;
        
        hVotes.put(candidate, count);
    }
    
}
                    
                

And the VotingBooth class:

                    
package org.springbyexample.vote;

public class VotingBooth {

    VoteRecorder recorder = null;
    
    public void setVoteRecorder(VoteRecorder recorder) {
        this.recorder = recorder;
    }
    
    public void vote(Candidate candidate) {
        recorder.record(candidate);
    }

}
                    
                

Now the LocalVoteRecorder class – the implementing class of the VoteRecorder interface -- is completely decoupled from the VotingBooth class. We have removed all hard-coded references to lower level classes. According to the rules of DIP, this is all we need to do in order to rid our code of RFI.

However, there is one problem with this implementation. We don’t have a main method. We definitely need one in order to run our application, and somewhere in this main method we will need to instantiate the LocalVoteRecorder.

By instantiating the LocalVoteRecorder in our main method, we would break Rule #1 of Dependency Inversion. We have coded to the abstraction, we have integrated our changes, but our application would still have a dependency on a lower level class.