views:

78

answers:

2

I have a factory class that decides which of four available subclasses it should instantiate and return. As you would expect, all subclasses implement the same interface:

public static class FooFactory{
     public IFoo CreateFoo(FooEnum enum){
            switch (enum)
            {
                case Foo1:
                    return new Foo1();
                case Foo2:
                    return new Foo2();
                 case Foo3:
                    return new Foo3(IBar);//has a constructor dependency on IBar
                case Foo4:
                    return new Foo4();
                 default:
                    throw new Exception("invalid foo!");
            }
     }
}

As you can see, one of the subclasses has a dependency defined in its constructor.

Some points of interest:

  • We're using Spring.NET as our IoC.
  • All subclasses of IFoo are domain objects and therefore are not being instantiated by Spring.NET. I'd like to keep things this way if at all possible.
  • The application has a hand written Data Access Layer (puke) so no ORM is in play here.

I'm trying to figure out how best to pass the IBar dependency into Foo3 from FooFactory. I get the feeling that this might be a problem best resolved via IoC but I can't quite grok how. I also want to keep FooFactory as unit testable as possible: i.e. I'd prefer not have to have dependencies on Spring.NET in my test code.

Thanks for reading.

+4  A: 

Change FooFactory to an Abstract Factory and inject the IBar instance into the concrete implementation, like this:

public class FooFactory : IFooFactory {
     private readonly IBar bar;

     public FooFactory(IBar bar)
     {
         if (bar == null)
         {
             throw new ArgumentNullException("bar");
         }

         this.bar = bar;
     }

     public IFoo CreateFoo(FooEnum enum){
            switch (enum)
            {
                case Foo1:
                    return new Foo1();
                case Foo2:
                    return new Foo2();
                 case Foo3:
                    return new Foo3(this.bar);
                case Foo4:
                    return new Foo4();
                 default:
                    throw new Exception("invalid foo!");
            }
     }
}

Notice that FooFactory is now a concrete, non-static class implementing the IFooFactory interface:

public interface IFooFactory
{
    IFoo CreateFoo(FooEnum emum);
}

Everywhere in your code where you need an IFoo instance, you will then take a dependency on IFooFactory and use its CreateFoo method to create the instance you need.

You can wire up FooFactory and its dependencies using any DI Container worth its salt.

Mark Seemann
Ok, I see your strategy and as I see it, supports what I said. Am I missing something? I wasn't suggesting _when_ to implement IOC, just that he needs to _not_ avoid using the IOC in his factory. +1 if you paste in some valid code ;-)
Sky Sanders
@Sky Sanders: It's better to avoid having the DI Container inside the factory. The factory is a domain object like anything else, and having the container inside the domain object leads to the Service Locator anti-pattern: http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
Mark Seemann
Maybe you should go tell uncle bob. lol. Thanks, I am reading..
Sky Sanders
Oh, I already did: http://blog.ploeh.dk/2010/01/25/DependencyInjectionInversionInNET.aspx
Mark Seemann
@Mark: Why use abstract factory instead of using a non derived class with a static Create() method? I don't plan on having more than one implementation of this factory. And if the need ever arises, I can use a re-factoring tool to extract an interface.
Dirk
On a general note, static factories are just Singletons with another name, and they are problematic for a number of reasons: http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons A static factory simply doesn't give you a good separation of concerns, and you may well end up using it in your code as a 'virtual new operator'. That, again, inreases class coupling. It has the same problems as the Service Locator anti-pattern: http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
Mark Seemann
On a specialized note, you asked whether DI could address your concerns, and it can. A major part of DI is about mapping interfaces to concrete classes, and that's what the Abstract Factory is all about. Besides reducing coupling, this is also a lot better for testability reasons, but I don't know whether that's relevant to you (it should be, though).
Mark Seemann
A: 

sounds like you want your cake and to eat it too. you need to commit to your IOC strategy.

you will produce mo an betta code and the chicks will dig you more too.... ;p

Sky Sanders
@Sky Sanders, I'm not sure which chicks you hang around with, but its not my experience that any of them will dig you more if you commit to an IoC strategy
Sam Holder
You don't have to commit to a particular DI Container until the very latest moment: http://stackoverflow.com/questions/2045904/dependency-inject-di-friendly-library/2047657#2047657
Mark Seemann
Part of my problem is figuring out where the factory and Inversion of Control patterns fall in the Dependecy Injection continuum. Perhaps you can provide a more enlightening response?
Dirk
@dirk: hold on a sec, I have something to learn...I admit, my response was a bit off-handed but it is what I was thinking... Let me look at mark's answer closer.
Sky Sanders
@sam: dude, chicks dig commitment. ask one. ;-)
Sky Sanders