Base classes as factories?

Question

I was writing some code over the weekend and I found myself wanting to write a factory as a static method in a base class.

My question is simply to know if this is a c# idomatic approach?

My sense that it might not be comes from the fact that the base class has knowledge of the derived class.

That said, I'm not sure of a simpler way to get the same result. A whole other factory class seems (to me at least) like unneeded complexity (?)

Something like:

class Animal
{
  public static Animal CreateAnimal(string name)
  {
     switch(name)
     {
        case "Shark":
          return new SeaAnimal();
          break;
        case "Dog":
          return new LandAnimal();
          break;
        default:
          throw new Exception("unknown animal");
     }
  }
}
class LandAnimal : Animal
{
}

class SeaAnimal : Animal
{
}

Answer 1

Well, the advantage of a separate factory class is that it can be mocked out in unit tests.

But if you're not going to do that, or make it polymorphic in any other way, then a static Factory method on the class itself is OK.

Answer 2

You could use Generics to avoid the switch statement and decouple the downstream implementations from the base class as well.:

 public static T CreateAnimal<T>() where T: new, Animal
 {
    return new T();
 }

Usage:

LandAnimal rabbit = Animal.CreateAnimal();  //Type inference should should just figure out the T by the return indicated.

or

 var rabbit = Animal.CreateAnimal<LandAnimal>(); 

Answer 3

Taken to the extreme, the factory could be generic as well.

interface IFactory<K, T> where K : IComparable
{
    T Create(K key);
}

Then one can create any type of factory of objects, which in turn could create any type of object. I am not sure if that is simpler, it is certainly more generic.

I don't see anything wrong with a switch statement for a small factory implementation. Once you are into large number of objects or possible different class hierarchies of objects, I think a more generic approach is better suited.

Answer 4

Bad idea. First, it violates the open-closed principle. For any new animal you would have to mess with your base class again and you would potentially break it. The dependencies would go the wrong way.

If you need to create animals from a configuration, a construct like this would be sort of OK, although using reflection to get the type that matches the name and instantiate it using that obtained type information would be a better option.

But you should create a dedicated factory class anyway, untied from the animal class hierarchy, and return an IAnimal interface rather than a base type. Then it would becomes useful, you would have achieved some decoupling.

Answer 5

This question is timely for me - I was writing almost exactly such code yesterday. Just replace "Animal" with whatever is relevant in my project, though I'll stick with "Animal" for the sake of discussion here. Instead of a 'switch' statement, I had a somewhat more complex series of 'if' statements, involving more than just comparing one variable to certain fixed values. But that's a detail. A static factory method seemed like a neat way to design things, as the design emerged from refactoring earlier quick-and-dirty messes of code.

I rejected this design on the grounds of the base class having knowledge of the derived class. If classes LandAnimal and SeaAnimal are small, neat, and easy, they can be in the same source file. But I have large messy methods for reading text files not conforming to any officially defined standards - I want my LandAnimal class in its own source file.

That leads to circular file dependency - LandAnimal is derived from Animal, but Animal needs to already know that LandAnimal, SeaAnimal and fifteen other classes exist. I pulled the factory method out, put it into its own file (in my main application, not my Animals library) Having a static factory method seemed cute and clever, but I realized that it didn't actually solve any design problem.

I have no idea how this relates to idiomatic C#, since I switch languages a lot, I usually ignore idioms and conventions peculiar to languages and dev stacks outside my usual work. If anything my C# might look "pythonic" if that's meaningful. I aim for general clarity.

Also, I don't know if there'd an advantage to using the static factory method in the case of small, simple classes unlikely to be extended in future work - having it all in one source file might be nice in some cases.