Question

As per my understanding both Factory class and Spring DI follows the Dependency injection. I mean in both the cases external entity is used to push the dependency. Right?
My question is which one i should go for between factory classes and Spring DI when my intention is just to get the objects . Assume i don’t want any other features like aop, dao support etc. Only purpose is to get the objects either from Factory class or Spring DI. Which one is preferable.

on some site read this statement

DI loosely coupled and less intrusive in comparison to Factory classes

But could not get how spring DI loosely coupled and less intrusive than factory classes?
in both the cases we have to insert some kind of get object code in our core program .

Answer 1

Spring DI promotes loosely coupled code because the Spring container injects your dependencies based on configuration. If you are injecting interface implementations, you don’t have to change code to change which specific implementation gets injected, unless you consider your configuration code, which many do.

If you use a Factory to create configured objects that are used by the rest of your code, you are writing code to create the objects, configure them, etc. If you want to change what the factory returns, you have to change actual code, which some would argue is a more intrusive change.

Typically Spring is used to configure how the various layers of your application are wired together. X service takes such and such DAO implementations, for example. That’s application level organization. Lets say you have a scenario where want to create a button for every row in a list — in that case you could use a factory to create the buttons. This scenario is based on a runtime situation where the GUI has different elements that you couldn’t configure up front (because its based on the data), so DI makes less sense here.

EDIT – based on your comment questions, I think the primary point here is that you have to consider is that Spring is also an Inversion of Control container. That means you don’t program in which components in your application go where. Without IoC, you might do something like

MyServiceImpl extends MyService {
    Dao1 = new Dao1Impl(); // you programmatically configure which components go in here
    Dao2 = new Dao2Impl();
    ....
}

instead you do something like

MyServiceImpl extends MyService {
    public Dao1;  // you haven't specified which components, only interfaces
    public Dao2;
    ....
}

In the second code sample, Spring (or whatever you use) will inject the appropriate DAO instances for you. You have moved control of which components to use to a higher level. So IoC and DI go hand and hand, IoC promotes loose coupling because in your component definitions (i.e. interfaces) you only specify behavior.

In other words, IoC and DI are not necessary for loose coupling; you can have loose coupling with a Factory too

MyServiceImpl extends MyService {
    public dao1 
    public dao2;

    MyServiceImpl(){
       dao1 = DaoFactory.getDao1();
       ...
    }
    ....
}

here your service still only depends on DAO definitions and you use the factory to get implementations. The caveat is that your service is now coupled to the factory. You can make it more loose by passing a Factory into your constructor if you want….

Also, dont forget that Spring provides other useful functionalities, like its transaction management. That’s incredibly helpful, even though you said for your app you don’t need it.