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?
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
posted
0
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?
The Factory pattern is typically implemented using static method calls in the object that has the dependency. This can make UnitTesting 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 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.
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.
0
