We have reduced coupling. But one question remains still—who will create the instance of the DataServiceImpl class and use it to create an instance of the BusinessServiceImpl class? If you have thousands of classes with a number of dependencies, you don't want to write the following code manually:

DataService dataService = new DataServiceImpl(); //Create

BusinessService businessService 
 = new BusinessServiceImpl(dataService);//Create and Wire

That's exactly where the Spring Framework comes into the picture. The core feature of the Spring Framework is to do exactly what the preceding code does.

Before diving into the Spring Framework, let's look at some terminology:

• Beans: In the preceding example, we created two objects—dataService and businessService. These two instances are called beans.
• Wiring: dataService does not have any dependencies. businessService has one dependency—dataService. We created dataService and provided it as an argument to the BusinessServiceImpl constructor. This is called wiring.
• DI: The process of identifying beans, creating them, and wiring dependencies is called DI. This is exactly what the preceding code does.
• IoC: When we started this example, BusinessServiceImpl was responsible for creating an instance of DataServiceImpl. By the end, we made the code loosely coupled and BusinessServiceImpl was no longer responsible for creating DataServiceImpl. This is also called IoC. We are shifting the responsibility of creating dependencies to a framework.