Factory class vs Spring DI

Question

In my understanding, the Factory and Spring DI class follows dependency injection. I mean, in both cases, an external entity is used to push dependency. Right? My question is which one should go between Factory and Spring DI classes when I only intend to get objects. Suppose I don't want any other features like support for aop, dao, etc. The only goal is to get objects from either the Factory class or Spring DI. Which one is preferable.

read this statement on some site

DI is loosely coupled and less intrusive than Factory classes

But failed to get how Spring DI is loosely coupled and less intrusive than Factory classes? in both cases, we must insert some kind of object code into our main program.

Answer 1

Spring DI promotes loosely coupled code because the Spring container injects your dependencies based on configuration. If you are implementing interface implementations, you do not need to change the code to change which particular implementation will be introduced unless you consider your configuration code, which many do.

If you use Factory to create customized objects that are used by the rest of your code, you write code to create objects, configure them, etc. If you want to change what Factory returns, you must change the actual code, which, according to some, will be a more intrusive change.

Typically, Spring is used to customize how the various layers of your application connect together. For example, service X accepts such and such DAO implementations. This organization is an application tier. Suppose you have a script in which you want to create a button for each line in the list — in this case, you could use Factory to create the buttons. This scenario is based on a run-time situation when the GUI has different elements that you could not configure in advance (because they are data-based), so the DI here is of less importance.

EDIT - based on your comments, I think the main point here is that you have to consider that Spring is also an Inversion of Control container. This means that you are not programming which components in your application go there. Without IoC, you can 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 example, Spring (or whatever you use) will introduce the appropriate DAO instances to you. You have taken control of which components will be used at a higher level. Thus, IoC and DI go hand in hand, IoC helps to loosen the connection, because in your component definitions (for example, interfaces) you specify only behavior.

In other words, IoC and DI are not needed for loose communication; You can have a free connection with Factory too

 MyServiceImpl extends MyService { public dao1 public dao2; MyServiceImpl(){ dao1 = DaoFactory.getDao1(); ... } .... } 

here, your service still depends only on the DAO definitions, and you use Factory to get the implementations. The caveat is that your service is now associated with a factory. You can make it freer by passing Factory to your constructor if you want ....

Also, keep in mind that Spring provides other useful features, such as transaction management. This is incredibly useful, although you said that you do not need this for your application.

Answer 2

Spring also uses factory. Just because the factory does not reference any application code, the factory connects everything together and passes them. If you use a factory similar to the DAO factory from one of your earlier questions, your code will have explicit links to this factory, where you either need to build it, or call static methods on it, and it's ugly. Using the explicit search method factory, if you want the test code to make fun of what was returned by the factory, you need to work on how the factory works, where with Spring you can set the test setup code for the implementation layout and connect it to the thing being tested.

Answer 3

But couldn't understand how spring DI is loosely coupled and less intrusive than factory classes? in both cases we have to insert some kind of get object code in our main program.

Spring makes it less intrusive because it uses reflection to automatically “inject / create” dependencies. Thus, your code does not need a link to the factory.

Spring is commonly used to create a "Singleton-like" object. People usually use special factories to temporarily dump an object (for example, request objects). In fact, often you do spring create and enter your own factories (i.e. factory factory).