Отвратительный взлом (фабричный метод базового класса, использующий отражение)

Вы должны почувствовать себя грязным. Вот мыло:

public static class InterestRateFactories
{
    static InterestRateFactories()
    {
        _factories = new List<IInterestRateFactory>();
        //  register default factories, although you can also register them elsewhere, like in your ioc setup
    }
    private static readonly List<IInterestRateFactory> _factories;
    public static void RegisterFactory(IInterestRateFactory factory)
    {
        _factories.Add(factory);
    }
    public static T ImpliedRate<T>(double factor, double time, DayCounter dayCounter)
        where T : NonCompoundedInterestRate
    {
        var factory = _factories.FirstOrDefault(x => x.CanCreate(typeof(T), false));
        if (factory == null)
        {
            throw new NotSupportedException("Cannot create a non-compounded implied interest rate of type " + typeof(T).Name);
        }
        return (T)factory.Create(factor, time, dayCounter);
    }
    public static T ImpliedRate<T>(double factor, double time, DayCounter dayCounter, Frequency frequency)
        where T : CompoundedInterestRate
    {
        var factory = _factories.FirstOrDefault(x => x.CanCreate(typeof(T), false));
        if (factory == null)
        {
            throw new NotSupportedException("Cannot create a compounded implied interest rate of type " + typeof(T).Name);
        }
        return (T)factory.Create(factor, time, dayCounter, frequency);
    }
}

public interface IInterestRateFactory
{
    bool CanCreate(Type nonCompoundedInterestRateType, bool compounded);
    NonCompoundedInterestRate Create(double factor, double time, DayCounter dayCounter);
    CompoundInterestRate Create(double factor, double time, DayCounter dayCounter, Frequency frequency);
}

Похоже, что вызывающий может так же легко вызвать фабричный метод производного класса, как и вызвать этот метод, передав производный тип как T.

Немного более явным контрактом здесь было бы добавить ограничение new () к T, вызвать ctor по умолчанию, а затем вызвать абстрактный метод Init, определенный в базовом классе.

У фабричного шаблона есть преимущество в тестируемости, но не в том виде, в котором вы его использовали здесь. Третья альтернатива - передать вызывающему объекту экземпляр фабричного класса для использования (метод ImpliedRate будет в фабричном интерфейсе). Это было бы удобно для модульного тестирования, но, возможно, обременительно для потребителя API.

Вместо статических методов вы можете использовать обычные методы и что-то вроде модифицированного шаблона клонирования / прототипа. Например:

public static class InstanceMap
{
    private static readonly Dictionary<Type,object> instances = 
        new Dictionary<Type,object>();

    public static void AddInstance(object instance)
    {
        instances[instance.GetType()] = instance;
    }

    public static T GetInstance<T>() { return (T) instances[typeof(T)]; }  
}

public interface INonCompoundedInterestRate
{
    INonCompoundedInterestRate ImpliedRate(double factor,
        double time,
        DayCounter dayCounter);
}

public class MyNonCompoundedInterestRate: INonCompoundedInterestRate
{
    public INonCompoundedInterestRate ImpliedRate(double factor,
        double time,
        DayCounter dayCounter) { /* do smth*/ }

    static MyNonCompoundedInterestRate()
    {
        InstanceMap.AddInstance(new MyNonCompoundedInterestRate());
    } 
} 

public abstract class InterestRate {
    public static T ImpliedRate<T>(
        double factor,
        double time,
        DayCounter dayCounter
    ) where T : INonCompoundedInterestRate 
    {
        return InstanceMap.GetInstance<T>().
            ImpliedRate(factor, time, dayCounter);
    }
    // ...
}

По моему опыту, вы можете создать только конструктор без параметров для универсального.

То, чего вы пытаетесь достичь, можно сделать только с помощью размышлений.

У вас всегда будут конфликты, пытаясь смешать статические (фабричные) методы с наследованием. Получить желаемое полиморфное поведение сложно. У меня была аналогичная проблема, и сейчас я использую отражение. Другой вариант, как уже упоминалось, - не использовать статические методы, если они не требуются. Тогда вы сможете использовать шаблонный метод или любую другую стратегию, которая будет хорошо работать с наследованием.

Есть ли причина не просто определять их в неуниверсальном интерфейсе, который объявлен на общих базах, а затем выполнять приведение к T? Я не вижу, чтобы передаются общие аргументы ...