Advantages of DI over factory pattern

[sachin yadav]

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]

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.

[sachin yadav]

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]

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.

[Nathan Pruett]

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]

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