Использование для статических универсальных классов?

Создание класса статическим не делает ' t добавлять какие-либо функции - это просто удобная проверка, если вы собираетесь использовать класс без его создания. И для этого есть несколько применений ...

Вы можете использовать статические универсальные классы, чтобы обойти ограничение: C # не допускает частичную специализацию. Это означает, что вы должны либо указать все параметры типа, либо ни одного. Однако это может быть излишне многословным.

Например:

static class Converter {
    public TOut Convert<TIn, TOut>(TIn x) {...}
}

предыдущий класс не разрешает вывод типа, поскольку вывод не работает с возвращаемыми значениями. Однако вы также не можете указать тип возвращаемого значения, не указав также тип ввода, поскольку вы не можете частично специализироваться. Используя (возможно, статический) универсальный класс, вы можете указать только один из двух типов:

static class ConvertTo<TOut> {
    public TOut Convert<TIn>(TIn x) {...}
}

Таким образом, вы можете разрешить вывод типа работать с типом параметра и указывать только возвращаемый тип.

(Хотя приведенный выше случай возможен, он, конечно, не требует, чтобы общий класс был статическим).

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

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

Например, я использую это в ValueUtils для хранения сгенерированных хэш-функций:

//Hash any object:
FieldwiseHasher.Hash(myCustomStructOrClass);

//implementation:
public static class FieldwiseHasher {
    public static int Hash<T>(T val) { return FieldwiseHasher<T>.Instance(val); }
}

public static class FieldwiseHasher<T> {
    public static readonly Func<T, int> Instance = CreateLambda().Compile();
    //...
}

Статические универсальные методы позволяют вывод типа сделать использование действительно простым; статические поля в общих классах позволяют хранить (мета) данные практически без накладных расходов . Меня совсем не удивит, если ORM, такие как Dapper и PetaPoco , будут использовать такие методы; но он также отлично подходит для (де) сериализаторов. Ограничением является то, что вы получаете низкие накладные расходы, потому что вы привязываетесь к типу времени компиляции ; если переданный объект на самом деле является экземпляром подкласса, вы, вероятно, привязываетесь к неправильному типу - и добавление проверок, чтобы избежать такого рода, подрывает преимущество низких накладных расходов.

Каковы основные применения статического универсального класса в C #? Когда их следует использовать ? Какие примеры лучше всего иллюстрируют их использование?

Я думаю, что в целом вам следует избегать создания параметров типа в статических классах, иначе вы не можете полагаться на вывод типов, чтобы сделать ваш клиентский код более кратким.

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

// static class with generics
public static class ListOps<T>
{
    public static List<T> Filter(List<T> list, Func<T, bool> predicate) { ... }
    public static List<U> Map<U>(List<T> list, Func<T, U> convertor) { ... }
    public static U Fold<U>(List<T> list, U seed, Func<T, U> aggregator) { ... }
}

// vanilla static class
public static class ListOps
{
    public static List<T> Filter<T>(List<T> list, Func<T, bool> predicate) { ... }
    public static List<U> Map<T, U>(List<T> list, Func<T, U> convertor) { ... }
    public static U Fold<T, U>(List<T> list, U seed, Func<T, U> aggregator) { ... }
}

Но классы эквивалентны, но какой из них легче использовать? Сравните:

// generic static class
List<int> numbers = Enumerable.Range(0, 100).ToList();
List<int> evens = ListOps<int>.Filter(numbers, x => x % 2 = 0);
List<string> numberString = ListOps<int>.Map(numbers, x => x.ToString());
int sumOfSquares = ListOps<int>.Fold(numbers, 0, (acc, x) => acc + x*x);

// vanilla static class
List<int> numbers = Enumerable.Range(0, 100).ToList();
List<int> evens = ListOps.Filter(numbers, x => x % 2 = 0);
List<string> numberString = ListOps.Map(numbers, x => x.ToString());
int sumOfSquares = ListOps.Fold(numbers, 0, (acc, x) => acc + b * b);

На мой взгляд, ListOps громоздкий и неуклюжий. Определение ванильного класса немного больше, но клиентский код легче читать - благодаря выводу типов.

В худшем случае C # не может определить типы, и вам придется указать их вручную. Вы бы предпочли написать ListOps .Map (...) или ListOps.Map (...) ? Я предпочитаю последнее.