This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes Advantages of DI over factory pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Advantages of DI over factory pattern" Watch "Advantages of DI over factory pattern" New topic
Author

Advantages of DI over factory pattern

sachin yadav
Ranch Hand

Joined: Nov 24, 2005
Posts: 156
Hi all,

Can someone please tell me what is the advantage of using spring dependency injection as compare to using factory pattern for creating beans on runtime?
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Basically, you can think of DI as a very configurable factory. And rather than coding all the sub-dependencies, specific classes used, and/or test versions vs. real versions yourself (and having to recompile) you just change the configuration.


-Nate
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
sachin yadav
Ranch Hand

Joined: Nov 24, 2005
Posts: 156
Nathan Pruett wrote:Basically, you can think of DI as a very configurable factory. And rather than coding all the sub-dependencies, specific classes used, and/or test versions vs. real versions yourself (and having to recompile) you just change the configuration.


I apologies if i misunderstood you, but don't you think that this can also easily be archived by using a factory and passing the new configuration class identifier. Can you please be a bit more detailed?
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
The Factory pattern is typically implemented using static method calls in the object that has the dependency. This can make Unit Testing very difficult. If something outside the object wires up the dependency, such as a Spring container, the dependency can easily be replaced with a different implementation in your tests.


kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

sachin yadav wrote:
Nathan Pruett wrote:Basically, you can think of DI as a very configurable factory. And rather than coding all the sub-dependencies, specific classes used, and/or test versions vs. real versions yourself (and having to recompile) you just change the configuration.


I apologies if i misunderstood you, but don't you think that this can also easily be archived by using a factory and passing the new configuration class identifier. Can you please be a bit more detailed?


It depends on what you mean by "easily be achieved"... so you make a configurable factory, and make it configurable through a class, the next logical step is to make a configuration class that reads information from a configuration file that you can change at runtime... and at this point you've just re-implemented what an existing DI container could do.

I can't really be more detailed about factories because they can range from the very simple (just returning statically defined instances ) or static methods wrapping constructor calls to complex configurable factories that can handle object hierarchies, etc.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

And as a funny note. You can still use Factories in Spring, and as a matter of fact, Spring used the Factory Method pattern a lot.

A FactoryBean is a Factory interface you can implement, and there are some already created for you in Spring. FactoryBean has a public Object getObject() method.

Also a BeanFactory, which is the underlying container holding all your beans created as, you can also see by the name is a factory, it has a method called public Object getBean(String name);

Also, in configuring a bean, if it is a legacy Factory class, then you set the bean's attribute called factory-method to the method that is the factory method in that class

What you won't get in just factories that DI gives, besides the great Unit Testing reason already given, is lifecycle management, and the ability to add features and services in configuration , rather than code, and if you change environments or implementation of services that you want, you can simply change the configuration, rather than having to create Factory classes for each environment, or write code that checks the environment to help determine which classes to create to return from the Factory.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Advantages of DI over factory pattern
 
Similar Threads
Factory disadvantages
Factory Pattern - help needed !!!!
Refactoring to Patterns - pattern questions
ejbhome
factory or abstract factory?