C# Generic factory pattern for n-derived objects (create all super-types)?
<p>I have a generic object factory <code>FactoryBase&lt;T&gt;</code> with a factory method:</p>

<pre><code>public abstract class FactoryBase&lt;T&gt; where T : new()
{
    public virtual T CreateInstance()
    {
        T thing = new T();

        // Tweak 'thing' a bit...

        return thing;
    }
}
</code></pre>

<p>This works great for creating concrete factories for various types:</p>

<pre><code>public class FruitFactory : FactoryBase&lt;Fruit&gt;
{
    public override Fruit CreateInstance()
    {
        Fruit fruit = base.CreateInstance();

        // Do some Fruit polishing stuff...

        return fruit;
    }
}
</code></pre>

<p>However, the pattern breaks down if I want to create a factory type derived from <code>Fruit</code>:</p>

<p><strong>First attempt: (WORKS, but INCORRECT)</strong></p>

<p>Here, <code>AppleFactory</code> directly inherits <code>FactoryBase&lt;Apple&gt;</code> -- this is wrong because <code>AppleFactory</code> should rely upon <code>FruitFactory</code> to build a nice polished <code>Fruit</code> upon which to build our <code>Apple</code>:</p>

<pre><code>// Should inherit FruitFactory, not FactoryBase
public class AppleFactory : FactoryBase&lt;Apple&gt;
{
    public override Apple CreateInstance()
    {
        Apple apple = base.CreateInstance();

        // FruitFactory is left out above, so...
        // ...we have to do all the Fruit polishing stuff...
        // ... and any apple stuff...

        return apple;
    }
}
</code></pre>

<p><strong>Second attempt: (Complete fail)</strong></p>

<p>Inheriting <code>FruitFactory</code> is clearly an error because it is non-generic and returns a <code>Fruit</code> not an <code>Apple</code>:</p>

<pre><code>// COMPILE ERRORS
public class AppleFactory : FruitFactory
{
    public override Apple CreateInstance()  // ERROR: Override method must return Fruit
    {
        Apple apple = base.CreateInstance(); // ERROR: FruitFactory returns a Fruit
        return apple;
    }
}
</code></pre>

<h2>The "Ugly" Solution?</h2>

<p>By refactoring <code>FruitFactory</code> into a generic<code>FruitFactory&lt;T&gt;</code> I can create a properly derived <code>AppleFactory</code>:</p>

<pre><code>public abstract class FruitFactory&lt;T&gt; where T : Fruit, new()
{
    public override T CreateInstance()
    {
        T fruit = (T)base.CreateInstance();

        // Do some Fruit polishing stuff...

        return fruit;
    }
}

// AppleFactory that property calls FruitFactory&lt;Apple&gt;
public class AppleFactory : FruitFactory&lt;Apple&gt;
{
    public override Apple CreateInstance()
    {
        Apple apple = base.CreateInstance();

        // ... ONLY apple stuff needed!!!

        return apple;
    }
}
</code></pre>

<p>I purposely make <code>FruitFactory&lt;T&gt;</code> abstract because it seems ugly and redundant for client code to call upon a a <code>FruitFactory&lt;Fruit&gt;</code>. Thus, I provide a non-generic <code>FruitFactory</code> which needs no body to be fully functional:</p>

<pre><code>// Concrete FruitFactory
public class FruitFactory : FruitFactory&lt;Fruit&gt; { }
</code></pre>

<h2>Complaints:</h2>

<p>Each time I need a factory for a more-derived type I have to convert the corresponding base type's factory to an abstract generic.</p>

<p>In other words, if I have a <code>FooFactory</code> I have to convert it to a <code>FooFactory&lt;T&gt;</code> in order to create <code>DerivedFooFactory : FooFactory&lt;DerivedFoo&gt;</code></p>

<p>Simultaneously, I must make a new concrete <code>FooFactory : FooFactory&lt;Foo&gt;</code>.</p>

<p>Or... I could the generic factories directly:</p>

<pre><code>var fruitFactory = new FruitFactory&lt;Fruit&gt;(); // Double-Fruity! sigh...
</code></pre>

<p>Is there a cleaner way to create an <code>AppleFactory</code> that first gets an <code>Apple</code> out of a <code>FruitFactory</code> without needing generic classes for each 'middle-man' type in the inheritance chain?</p>

<p>Note: I really don't want to use reflection or complex schemes.</p>
