The basic concept of the Inversion of Control pattern (also known as dependency injection) is that you do not create your objects but describe how they should be created.
Take the following example of a loan processing application. For simplicity the Loan process system carries out three steps—Customer Address verification, Credit verification, and Loan assessment. Each of these steps is implemented as Java classes, VerifyAddress
, VerifyCredit,
and LoanAssessment
, respectively. Now, in traditional application development without IoC, the following code snippet would be used by the Loan processing application to carry out the loan processing as part of the appyLoan()
method shown below:
package demo.spring; public class LoanProcessImpl { public Loan applyLoan(Loan loan) { VerifyAddress verifyAddress = new VerifyAddressImpl(); VerifyCredit verifyCredit = new VerifyCreditImpl(); LoanAssessment loanAssessment = new LoanAssessmentImpl(); //Step one - verify address boolean validAddress = verifyAddress.verifyAddress(loan.getCustomer().getAddress()); if(!validAddress){ throw new RuntimeException("Address for Customer SSN "+loan.getCustomer().getSSN() + " is not valid"); } //Step two -verify credit String status = verifyCredit.verifyCredit(loan.getCustomer()); if(status.equalsIgnoreCase(VerifyCredit.BAD_CREDIT)){ //If bad credit, disapprove Loan loan.setLoanStatus(LoanAssessment.LOAN_REJECTED); return loan; }else { return loanAssessment.assessLoan(loan); } } }
As you see in the previous code, in the applyLoan()
method we have created an instance of VerifyAddress
, VerifyCredit,
and LoanAssessment
objects. If any of these objects is dependant on other objects, then it needs to be instantiated in that scope (that is, in that class or method). These dependencies can grow based on our application, and manageability could become a difficult task. You may not realize that most of the time your object would be stateless and would eventually require one shared instance of object in your application, rather than creating a creating a new object for every request. Apart from object creation, you could also have configuration in your code, such as looking up the Data source connection factory using JNDI.
Applying IoC principles would make your design modular and move the object creation code and configuration outside of the application code and manage these dependency in an external configuration file. A container (like the Spring framework's IoC container) then uses the external configuration file to create the beans, manage the dependency and assemble the application from these loosely coupled beans. In the Spring IoC application section, we will look at how to apply IoC principles using Spring by taking the example of the Loan application that we discussed above.