Статический родовой класс как словарь - PullRequest
Новая
       33

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

17 голосов
/ 26 марта 2009

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

Это лучше или хуже статического словаря независимо от >?

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

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 ищет статические поля по параметру универсального типа?

Ответы [ 4 ]

13 голосов
/ 26 марта 2009

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

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

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

2 голосов
/ 26 марта 2009

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

1 голос
/ 26 марта 2009

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

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

1 голос
/ 26 марта 2009

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

...