Inversion of Control and Dependency injection

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. 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.

i.e., 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.

Hi Gibu..
 
               Could you please tell me a little more on this line?

             >> 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.

              I dont really get, "You do not create your objects but describe how they should be created"

Hi brunoguimaraes,

                      Your examply definitely cleared my mind bit more....  but why do we want to do this? what harm one can encounter if we instantiate the Service right there

See gibu_george's second post, he explains all the benefits (less code, loose coupling, etc).

ok got it.
Please correct me if I am wrong...

Lets say I made a class abc.

Now there is another class xyz, thats need a reference to the object of class abc.
so instead of doing abc newObject = new abc();  in xyz class....

we define this in XML file amd Spring framework, automatically creates that object when required by xyz class?

I am sorry, Asking too much stuff...

Yes, that is correct. But you don't wanna do this for every attribute in your class. Typically you have an attribute that is an interface, and in the config file you say which implementation class you want to use.

For example:

// an interface that defines methods for connecting to a database, and other DB related stuff
public interface IDao {
}
 
// an implementation of that interface, specific to Oracle databases
public class OracleDao implements IDao {
}
 
// an implementation of that interface, specific to MySql databases
public class MySqlDao implements IDao {
}
 
// business class that need the dao's methods
public class BusinessObject() {
  
   private IDao dao;   
}
 
// XML file
<bean id="oracleDao" class="com.ee.OracleDao" />
<bean id="mySqlDao" class="com.ee.MySqlDao" />
<bean id="businessObject" class="com.ee.BusinessObject">
     <!-- here you choose which implementation to use. it is currently using Oracle, but if you want to change databases later, you just replace ref="oracleDao" for ref="mySqlDao", and there is no need to recompile the code -->
    <property name="dao" ref="oracleDao" />
</bean>

Select allOpen in new window

Got it,
            This was a very good example for a beginner like me :-)

           So this is what whole dependency injection is.

            Thank you...

You're welcome!

Thanks folks:)