Object factory from interface types
There is a very simple way to handle this but that is all dependant on the fact you have only one implementation of each ISprite impelementation per interface type. If thats the case (and they all have parameterless constructors) you can simply use reflection to get your type and then construct it.

class SpriteFactory : ISpriteFactory
{
    public T Create&lt;T&gt;() where T : ISprite
    {
        var type = typeof(T);
        var spriteType = AppDomain.CurrentDomain.GetAssemblies()
                                                .SelectMany(s =&gt; s.GetTypes())
                                                .Where(p =&gt; type.IsAssignableFrom(p) &amp;&amp; p.IsClass)
                                                .FirstOrDefault();

        if (spriteType == null)
            return default(T);

        return (T)Activator.CreateInstance(spriteType);
    }
}


Now there is alot wrong with this implementation as it assumes alot.


That there is only one implenetation of the ISprite type passed in.
It does an assembly scan everytime you need to create a new instance of this object.
Requires all implementations to have a default parameterless constructor on the implementation.


We could approach this by only scanning for the object once. But again we are stuck with the issues in point 1 and 3. This implementation is even uglier and (not tested) doesn't appear to be too thread safe.

class SpriteFactory : ISpriteFactory
{
    static object _locker = new object();

    Dictionary&lt;Type, Type&gt; registrations = new Dictionary&lt;Type, Type&gt;();

    public T Create&lt;T&gt;() where T : ISprite
    {
        var type = typeof(T);
        if (!registrations.ContainsKey(type))
        {
            lock (_locker)
            {
                var spriteType = AppDomain.CurrentDomain.GetAssemblies()
                                                        .SelectMany(s =&gt; s.GetTypes())
                                                        .Where(p =&gt; type.IsAssignableFrom(p) &amp;&amp; p.IsClass)
                                                        .FirstOrDefault();
                registrations[type] = spriteType;
            }
        }
        var regType = registrations[type];
        return regType != null ? (T)Activator.CreateInstance(regType) : default(T);
    }
}


What you are really after is some sort of dependency injection and do away with the SpriteFactory all together. Dependency injection was made for this type of work and although the initial code is usually a bit more its typically more elegant. Especially when it comes to managing constructor injection, object disposal etc. The real power comes in when you need to start extending your application and adding more types. 

Now without depenency injection you could define your registrations some where else. Where although it is similar to your first approach does abstract the implementation. Something like.

interface ISpriteFactory
{
    T Create&lt;T&gt;() where T : ISprite;
}

class SpriteFactory : ISpriteFactory
{
    static Dictionary&lt;Type, Func&lt;object&gt;&gt; registrations = new Dictionary&lt;Type, Func&lt;object&gt;&gt;();

    public static void AddRegistration&lt;T&gt;(Func&lt;T&gt; aquire)
    {
        registrations[typeof(T)] = aquire as Func&lt;object&gt;;
    }

    public T Create&lt;T&gt;() where T : ISprite
    {
        if (registrations.ContainsKey(typeof(T)))
            return (T)registrations[typeof(T)]();
        return default(T);
    }
}


Now what I have done is basically created static method to create registrations of your ISprite implementations.  This can be used as such.

class Program
{
    static void Main(string[] args)
    {
        SpriteFactory.AddRegistration&lt;IPieceSprite&gt;(() =&gt; new PieceSprite());
        SpriteFactory.AddRegistration&lt;ITileSprite&gt;(() =&gt; new TileSprite());

        var factory = new SpriteFactory();

        var piece = factory.Create&lt;IPieceSprite&gt;();
    }
}


All in all without a proper framework in place to take care of your dependency resolution and life-time scopes you are stuck with either having our initial 3 problems or writing out your object creation methods manually.