views:

3799

answers:

9

Most of the examples quoted for usage of Dependency Injection, we can solve using the factory pattern as well. Looks like when it comes to usage/design the difference between dependency injection and factory is blurred or thin.

Once someone told me that its how you use it that makes a difference!

I once used StructureMap a DI container to solve a problem, later on I redesigned it to work with a simple factory and removed references to StructureMap.

Can anyone tell me what is the difference between them and where to use what, whats the best practice here?

+11  A: 

I would suggest to keep the concepts plain and simple. Dependency Injection is more of a architectural pattern for loosely coupling software components. Factory pattern is just one way to separate the responsibility of creating objects of other classes to another entity. Factory pattern can be called as a tool to implement DI. Dependency injection can be implemented in many ways like DI using constructors, using mapping xml files etc.

Perpetualcoder
+1  A: 

With dependency injection the client does not need to get its dependencies on its own, its all prepared beforehand.

With factories, someone has to call those to get the generated objects over to the place where they are needed.

The difference lies mostly in this one line where calling the factory and fetching the constructed object is done.

But with factories you have to write this 1 line everywhere you need such an object. With DI you just have to create the wiring (relation between usage and created object) once and just rely on the presence of the object afterward everywhere. On the other side, DI often requires a bit more (how much depends on the framework) work on the preparation side.

Kosi2801
+2  A: 

I believe DI is a type of abstraction layer on factories, but they also provide benefits beyond abstraction. A true factory knows how to instantiate a single type and configure it. A good DI layer provides the ability, through configuration, to instantiate and configure many types.

Obviously, for a project with a few simple types that requires relatively stable business logic in their construction, the factory pattern is simple to understand, implement, and works well.

OTOH, if you have a project containing numerous types whose implementations you expect to change often, DI gives you the flexibility through its configuration to do this at runtime without having to recompile your factories.

Will
+17  A: 

When using a factory your code is still actually responsible for creating objects, by DI you outsource that responsibility to a framework which is separate from your code.

willcodejavaforfood
interesting use of the term outsource :) +1
Perpetualcoder
I agree -- very understandable in a few words.
Chuck Conway
The DI pattern does not require any frameworks. You can do DI by manually writing factories which do DI. DI frameworks just make it easier.
Esko Luontola
@Perpetualcoder - Thanks@Esko - Dont get caught up on the word framework meaning some advanced 3rd party library.
willcodejavaforfood
+11  A: 

There are problems which are easy to solve with dependency injection which are not so easily solved with a suite of factories.

Some of the difference between, on the one hand, inversion of control and dependency injection (IOC/DI), and, on the other hand, a service locator or a suite of factories (factory), is:

IOC/DI is a complete ecosystem of domain objects and services in and of itself. It sets everything up for you in the way you specify. Your domain objects and services are constructed by the container, and do not construct themselves: they therefore do not have any dependencies on the container or on any factories. IOC/DI permits an extremely high degree of configurability, with all the configuration in a single place (construction of the container) at the topmost layer of your application (the GUI, the Web front-end).

Factory abstracts away some of the construction of your domain objects and services. But domain objects and services are still responsible for figuring out how to construct themselves and how to get all the things they depend on. All these "active" dependencies filter all the way through all the layers in your application. There is no single place to go to configure everything.

Justice
+2  A: 

i believe that DI is a way of configurings or instantianting a bean. The DI can be done in many ways like constructor, setter-getter etc.

Factory pattern is just another way of instantiating beans. this pattern will be used mainly when you have to create objects using factory design pattern,because while using this pattern you dont configure the properties of a bean, only instantiate the object.

Check this link :Dependency Injection

harshit
+1  A: 

Binoj,

I don't think you have to choose one over the other.

The act of moving a dependent class or interface to a class constructor or setter follows the DI pattern. The object you pass to the constructor or set can be implemented with Factory.

When to use? Use the pattern or patterns that are in your developer wheelhouse. What do they feel the most comfortable with and find easiest to understand.

-jason

Jason Slocomb
+2  A: 

Take a look at following chapter, it has a good comparison of Factory, Service Locator and DI pattern: http://books.google.com/books?id=vRxAnRb3mb4C&pg=PP1&dq=Danijel+Arsenovski#PPA408,M1

Dan
A: 

My thoughts:

Dependecy Injection: pass collaborators as parameters to the constructors. Dependency Injection Framework: a generic and configurable factory to create the objects to pass as parameters to the constructors.

bloparod