Статический общий класс как словарь

Статическое поле в родовом классе будет иметь отдельное значение для каждой комбинации общих параметров. Поэтому его можно использовать в качестве словаря < Type, whatever >

Это лучше или хуже статического словаря < Type, whatever > ?

Иными словами, какая из этих реализаций более эффективна?

public static class MethodGen<TParam> {
    public static readonly Action<TParam> Method = CreateMethod();
    static Action<TParam> CreateMethod() { /*...*/ }
}

Или

public static class MethodGen {
    static readonly Dictionary<Type, Delegate> methods 
              = new Dictionary<Type, Delegate>();

    public static Action<T> GetMethod<T>() {
        //In production code, this would ReaderWriterLock

        Delegate method;
        if(!methods.TryGetValue(typeof(T), out method)
            methods.Add(typeof(t), method = CreateMethod<T>());
        return method;
    }

    static Action<T> CreateMethod<T>() { /*...*/ }
}

В частности, как CLR ищет статические поля с помощью параметра типового типа?

Ответ 1

Мне нравится использовать общие типы таким образом. В частности, у меня часто есть частные вложенные родовые классы именно для этой цели.

Главное, что мне нравится в этом, - это то, что не нужно правильно инициализировать этот путь (с точки зрения безопасности потоков), учитывая, как работает инициализация типа. Единственная проблема заключается в том, что делать, если инициализация терпит неудачу - иногда я прибегаю к тому, чтобы вспомнить исключение, чтобы набросать первый необходимый доступ, но это довольно редко.

Я не хотел бы точно угадывать, как CLR ищет тип с помощью аргументов типа, но я уверен, что он будет оптимизирован для черновой и обратной:)

Ответ 2

Я не профилировал его (это единственный способ действительно ответить на этот вопрос - разница в производительности может быть настолько мала, чтобы быть бессмысленной), но я бы рискнул предположить, что блокировка - это дорогая часть. CLR делает блокировку для вас - и делает это так, как это определено специалистами в этой области! - поэтому я ожидаю, что если будет разница, было бы полезно использовать функцию языка, а не строить ее самостоятельно с помощью Dictionary + locking.

Ответ 3

Он не сохраняет значения для каждого параметра типового типа столько, сколько он действительно создает (концептуально в любом случае) N отдельных классов - по одному для каждого типа T, с которым вы его используете.

Ответ 4

Я считаю, что общая (первая) версия будет выполнять поиск по словарю во время компиляции и, следовательно, лучше работать во время выполнения.

Однако он может использовать больше памяти.