DI and IOC

DI and IOC

Using the DI is to way of getting the decoupling in java.  Using the DI we are not create/instantiate the object of the Depenadant class.

We are explaing the Dependcy injection in below example:

We have CD and we want to play this CD into CDPlayer.  So we are createing two classes which is shown below:

interface CD{                                                   class CDPlayer{

//methods                                                               CD  = new HindiCD();

                                                                               //method to use CD to play...

}                                                                         }

HindiCD, EnglishCD are implement into the CD class.

But we are doing the code in such way that of CDPlayer it play only the HindiCD.  If you want to play the English song then you will be open the CD player and remove the Hindi CD and insert the English CD into CD player.

In terms of programmer,  we are edit the CDPlayer class.  Remove the HindiCD to EnglishCD.  Recompile the CDPlayer class. and then run it.  But it is not feasible solution.

class CDPlayer{

CD = new EnglishCD();

}

So,  in such a way we create a tight coupling between the CDPlayer and HindiCD/ EngishCD class.  It means we are creating class which bind with the HindiCD at compile time or we can say that compiler know the CD object at the compile time and bind with it at compile time.  

So its mean when you want to change the CD then we are edit the CDPlayer class and recompile and run it.  But it worthless and not feasible solution.

Take another approch

He make the 2 in 1 CD player.  It means we put the 2 CD at time. Then our programmer achieve this thing using below code:

class CDPlayer{

CDPlayer(String typeCD){

Switch(typeCD){

case “Hindi”://

CD = new HindiCD();

case “English://

CD = new EnglishCD();

}

}

}

But if you some one want to play Gujarti songs then:

we must edit the CDPlayer class and upended into the switch case.  It means your class will be grown with the time and more complex on later.  So this is also not a feasible solution.  

Our aim to Our CDPlayer class read every CD without change its code. It’s remove only when we  create an object of CD at run time rather than at compile time.  That’s why we insert one container which did that work for us.  

Container created a CD object for us at runtime using the reflection API.

That's why we can insert the CD though a constructor into the class but how the CD player object created using the container which shown below

beans.xml

<bean id=”hiind”  class=”HindiCD with package name”>

…..

</bean>

So container injected dependency at the run time not at compile time.So we can say that container inject the (CD) dependency into the CDPlayer class at run time.  we are injected the dependency into two way :

1. Constructor injection
2. setter Injection

Benefit of DI:

1. Decouple the classes using DI and code is more readable and flexible.
2. Remove the complexity into large project
3. Unit testing is easy to do
4. An automatic add new functionality without affecting the other class.  If you want to SpenishCD then simply implement the CD interface and add into the container.  No other classes are affected in such a way.

IOC:

In the traditional, Approach JVM create first an Object of A after that it creates an object of B and last create an object of C.  This is a traditional way to create an object by JVM using object tree...

But in Spring we are using the container.  Container first create of the object of C and then it inject C object into B class.  Same way down it further.. Such a way,  we inverts the flow of creation of objects.  So that's why we called this is an Inversion of control..

• Dependency Injection (DI) is a pattern of injecting a class’s dependencies into it at runtime. This is achieved by defining the dependencies as interfaces, and then injecting in a concrete class implementing that interface to the constructor. This allows you to swap in different implementations without having to modify the main class. The Dependency Injection pattern also promotes high cohesion by promoting the  Single Responsibility Principle (SRP), since your dependencies are individual objects which perform discrete specialized tasks like data access (via DAOs) and business services (via Service and Delegate classes) .

• The Inversion of Control Container (IoC) is a container that supports Dependency Injection. In this you use a central container  like Spring framework, Guice, or HiveMind, which defines what concrete classes should be used for what dependencies throughout your application. This brings in an added flexibility through looser coupling, and it makes it much easier to change what dependencies are used on the fly. The basic concept of the Inversion of Control pattern is that you do not create your objects but describe how they should be created. You don’t directly connect your components and services together in code but describe which services are needed by which components in a configuration file. A container (in the case of the Spring framework, the IOC container) is then responsible for hooking it all up. Applying IoC, objects are given their dependencies at creation time by some external entity that coordinates each object in the system. That is, dependencies are injected into objects. So, IoC means an inversion of responsibility with regard to how an object obtains references to collaborating objects.