ClassFactories vs dependancy injection

Can someone explain when would I want to prefer one over the other? Thanks, -Chris

Message 1 of 7
, Jan 25, 2010

0 Attachment

Can someone explain when would I want to prefer one over the other?

Thanks,
-Chris

Scott Bain

It s an interesting question, Chris. Thanks for posting it. There are some ways in which this is an either/or question (ways in which DI and factories relate)

Message 2 of 7
, Jan 25, 2010

0 Attachment

It’s an interesting question, Chris. Thanks for
posting it.

There are some ways in which this is an either/or question (ways
in which DI and factories relate) and some ways in which it is not (where they have
different motivations).

Some ways they relate…

1.They both Separate the use of something from its creation, which
I think is a good separation of concerns.

2.They both also help encapsulate variation (if the object being
injected/constructed varies, as is usually the case).

Some ways they are more different…

1.Factories help to encapsulate business rules in a single
place. If, for instance, you are building a decorator chain of various
behaviors, then a factory can impose rules about what chains can be built and
which cannot, or which should be built under what circumstances. If a
client object builds the chain to inject it into a service, and the service has
more than one client, then the rules are spread out and often redundant.

2.DI, on the other hand, can be very useful in breaking dependencies
for testing (it is easy to inject a mock directly if the dependency is already “inject-able”,
for example). If you let a factory “decide” to build a mock,
then the factory can get coupled to testing issues.

Of course, they can be used together as well. A Client can
use a factory to build a dependency, and then inject what the factory built
into the Service. A test could inject a mock instead, ignoring the
factory. This can be overkill, of course, but if one needs the benefits
of both, one can use them in this way.

There are some ways in which this is an either/or question (ways
in which DI and factories relate) and some ways in which it is not (where they have
different motivations).

Some ways they relate…

1.They both Separate the use of something from its creation, which
I think is a good separation of concerns.

2.They both also help encapsulate variation (if the object being
injected/constructed varies, as is usually the case).

Some ways they are more different…

1.Factories help to encapsulate business rules in a single
place. If, for instance, you are building a decorator chain of various
behaviors, then a factory can impose rules about what chains can be built and
which cannot, or which should be built under what circumstances. If a
client object builds the chain to inject it into a service, and the service has
more than one client, then the rules are spread out and often redundant.

2.DI, on the other hand, can be very useful in breaking dependencies
for testing (it is easy to inject a mock directly if the dependency is already “inject-able”,
for example). If you let a factory “decide” to build a mock,
then the factory can get coupled to testing issues.

Of course, they can be used together as well. A Client can
use a factory to build a dependency, and then inject what the factory built
into the Service. A test could inject a mock instead, ignoring the
factory. This can be overkill, of course, but if one needs the benefits
of both, one can use them in this way.

Why one or the other? DI essentially just says (one interpretation) that the agency in charge of creating objects and tying them together should not be the

Message 4 of 7
, Jan 25, 2010

0 Attachment

Why one or the other?

DI essentially just says (one interpretation) that the agency in charge of creating objects and tying them together should not be the (base/domain/business/bean) objects themselves.
Factories can be seen as just accessors and modifiers (getters and setters) on object in the process of being created.

In fact, just the other day I used a static factory for to create objects for Spring (java) to inject (because I needed an parameter of type Class<T> which Spring has a little trouble with).

I m fairly certain that Scott summed up the issues nicely. I ll admit, I don t know what the term ClassFactories means and could interpret it one of two

Message 5 of 7
, Jan 25, 2010

0 Attachment

I’m fairly certain that Scott summed up the issues
nicely. I’ll admit, I don’t know what the term “ClassFactories”
means and could interpret it one of two ways…

Way #1:

public class ToBeBuilt {

private ToBeBuilt() { }

// this is my class factory

public static ToBeBuilt GetInstance() {

}

}

Way #2:

public class ToBeBuilt {

}

// this is my class factory:

public class BuildsObjects {

public ToBeBuilt MakeRequestedObject() {

}

}

Practically speaking (for myself only), I’m fairly
inflexible in this area when it comes to code I am writing. Thanks to
Scott, I always do Way #1. I do this on principle: Construction is
simple too intimate a detail for a class to expose.

I vary between Way #2 and dependency injection based on whether or
not procurement of a new object is a behavior of the client I am writing and
whether or not the client object uses the dependent object. I do this
according to the following rules:

When the client…

·…uses but does not procure: Pass
object in at the time when variation should occur

·…uses and procures: Pass
in some kind of provider (a Builder, an Abstract Factory, etc.) when the
variation should occur

·…procures but does not use: Directly
invoke the GetInstance() of the right object at the right time

·…procures and does not use but the
above approach would be difficult to test: Reevaluate design;
fall back on passing in some kind of provider

·…doesn’t procure and does not
use: Um. Hmm. Is this really a dependency or is it just
idle coupling?

Note that “use” includes using an object as the input
for the creation of another object.

Anyway. I’m not sure if this is directly related to
your question or just tangentially related but that’s never stopped me
before.

There are some ways in which this is an
either/or question (ways in which DI and factories relate) and some ways in
which it is not (where they have different motivations).

Some ways they relate…

1.They both Separate the use of something
from its creation, which I think is a good separation of concerns.

2.They both also help encapsulate
variation (if the object being injected/constructed varies, as is usually the
case).

Some ways they are more
different…

1.Factories help to encapsulate business
rules in a single place. If, for instance, you are building a decorator
chain of various behaviors, then a factory can impose rules about what chains
can be built and which cannot, or which should be built under what
circumstances. If a client object builds the chain to inject it into a
service, and the service has more than one client, then the rules are spread
out and often redundant.

2.DI, on the other hand, can be very
useful in breaking dependencies for testing (it is easy to inject a mock
directly if the dependency is already “inject-able”, for
example). If you let a factory “decide” to build a mock, then
the factory can get coupled to testing issues.

Of course, they can be used together as
well. A Client can use a factory to build a dependency, and then inject
what the factory built into the Service. A test could inject a mock
instead, ignoring the factory. This can be overkill, of course, but if one
needs the benefits of both, one can use them in this way.

It is a general question. I was reading around on the issue, and there is a strong push to favor DI over class factories. The thing that concerned me is the

Message 6 of 7
, Feb 1, 2010

0 Attachment

It is a general question.

I was reading around on the issue, and there is a strong push to favor DI over class factories. The thing that concerned me is the religiousness of it, as if DI where the higher evolved form of coding. Two reasons that I thought were interesting are: 1) class factories violate the open / close principal, and 2) Heavy use of class factories results in a lot of class factories in your project. Given how they are used, I'm not sure I care about #1, and at least in the size of the projects I am doing, #2 hasn't been an issue.

As I learned more, I realized I didn't really phrase the question well. While I have found dependency injection to be very useful when properly applied, my larger concern is with the large and complex dependency injection frameworks. So far I've only worked on one project that used a framework and while I could see some advantages - it wasn't done very well (IMO). There was still a lot of coupling in that if I wanted to change the source of data to be anything other than a database it would involve a significant effort. It also added a learning curve just trying to understand what instances of which object would be created when.

So far, the answer I have gathered from the group is that it isn't an either/or answer  they are different tools for different situations.

I'm going to post my question about DI frameworks on a separate thread.

--- In leanprogramming@yahoogroups.com, Christopher Sage <bigbuffwolf@...> wrote:
>
> It would also depend upon what your goal is. Is there anything in
> particular you're trying to solve, or is this just a general question?
>
> -Chris
>
> On Mon, Jan 25, 2010 at 12:14 PM, Scott Bain <slbain@...>wrote:
>
> >
> >
> > It's an interesting question, Chris. Thanks for posting it.
> >
> >
> >
> > There are some ways in which this is an either/or question (ways in which
> > DI and factories relate) and some ways in which it is not (where they have
> > different motivations).
> >
> >
> >
> > Some ways they relate
> >
> > 1. They both Separate the use of something from its creation, which
> > I think is a good separation of concerns.
> >
> > 2. They both also help encapsulate variation (if the object being
> > injected/constructed varies, as is usually the case).
> >
> >
> >
> > Some ways they are more different
> >
> > 1. Factories help to encapsulate business rules in a single place.
> > If, for instance, you are building a decorator chain of various behaviors,
> > then a factory can impose rules about what chains can be built and which
> > cannot, or which should be built under what circumstances. If a client
> > object builds the chain to inject it into a service, and the service has
> > more than one client, then the rules are spread out and often redundant.
> >
> > 2. DI, on the other hand, can be very useful in breaking
> > dependencies for testing (it is easy to inject a mock directly if the
> > dependency is already "inject-able", for example). If you let a factory
> > "decide" to build a mock, then the factory can get coupled to testing
> > issues.
> >
> >
> >
> > Of course, they can be used together as well. A Client can use a factory
> > to build a dependency, and then inject what the factory built into the
> > Service. A test could inject a mock instead, ignoring the factory. This
> > can be overkill, of course, but if one needs the benefits of both, one can
> > use them in this way.
> >
> >
> >
> > That's my first bit of thinking, anyway. Let's see what others say.
> >
> >
> >
> > -Scott-
> >
> >
> >
> > *From:* leanprogramming@yahoogroups.com [mailto:
> > leanprogramming@yahoogroups.com] *On Behalf Of *chrishand40
> > *Sent:* Monday, January 25, 2010 9:44 AM
> > *To:* leanprogramming@yahoogroups.com
> > *Subject:* [leanprogramming] ClassFactories vs dependancy injection
> >
> >
> >
> >
> >
> > Can someone explain when would I want to prefer one over the other?
> >
> > Thanks,
> > -Chris
> >
> >
> >
>

Kim Gräsman

Hello, ... I don t have a clear opinion either way, but I read this the other day, and it seems to touch on a couple of your concerns:

Message 7 of 7
, Feb 1, 2010

0 Attachment

Hello,

On Mon, Feb 1, 2010 at 09:20, chrishand40 <cj.hand@...> wrote:
>
> It is a general question.
>
> I was reading around on the issue, and there is a strong push to favor DI over class factories. The thing that concerned me is the religiousness of it, as if DI where the higher evolved form of coding. Two reasons that I thought were interesting are: 1) class factories violate the open / close principal, and 2) Heavy use of class factories results in a lot of class factories in your project. Given how they are used, I'm not sure I care about #1, and at least in the size of the projects I am doing, #2 hasn't been an issue.
>
> As I learned more, I realized I didn't really phrase the question well. While I have found dependency injection to be very useful when properly applied, my larger concern is with the large and complex dependency injection frameworks. So far I've only worked on one project that used a framework and while I could see some advantages - it wasn't done very well (IMO). There was still a lot of coupling in that if I wanted to change the source of data to be anything other than a database it would involve a significant effort. It also added a learning curve just trying to understand what instances of which object would be created when.
>
> So far, the answer I have gathered from the group is that it isn't an either/or answer – they are different tools for different situations.