Необходимость построения полного специального обобщенного класса коллекции возникает редко; однако ключевое слово where допускается использовать также в обобщенных методах. Например, если нужно гарантировать, что метод Swap() может работать только со структурами, измените его код следующим образом:

// Этот метод меняет местами любые структуры, но не классы.

static void Swap(ref T a, ref T b) where T : struct

{

  ...

}

Обратите внимание, что если ограничить метод Swap() в подобной манере, то менять местами объекты string (как было показано в коде примера) больше не удастся, т.к. string является ссылочным типом.

Отсутствие ограничений операций

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

// Ошибка на этапе компиляции! Невозможно

// применять операции к параметрам типа!

public class BasicMath

{

  public T Add(T arg1, T arg2)

  { return arg1 + arg2; }

  public T Subtract(T arg1, T arg2)

  { return arg1 - arg2; }

  public T Multiply(T arg1, T arg2)

  { return arg1 * arg2; }

  public T Divide(T arg1, T arg2)

  { return arg1 / arg2; }

}

К сожалению, приведенный выше класс BasicMath не скомпилируется. Хотя это может показаться крупным недостатком, следует вспомнить, что обобщения имеют общий характер. Конечно, числовые данные прекрасно работают с двоичными операциями С#. Тем не менее, справедливости ради, если аргумент <Т> является специальным классом или структурой, то компилятор мог бы предположить, что он поддерживает операции +, -, * и /. В идеале язык C# позволял бы ограничивать обобщенный тип поддерживаемыми операциями, как показано ниже:

// Только в целях иллюстрации!

public class BasicMath where T : operator +, operator -,

  operator *, operator /

{

  public T Add(T arg1, T arg2)

  { return arg1 + arg2; }

  public T Subtract(T arg1, T arg2)

  { return arg1 - arg2; }

  public T Multiply(T arg1, T arg2)

  { return arg1 * arg2; }

  public T Divide(T arg1, T arg2)

  { return arg1 / arg2; }

}

Увы, ограничения операций в текущей версии C# не поддерживаются. Однако достичь желаемого результата можно (хотя и с дополнительными усилиями) путем определения интерфейса, который поддерживает такие операции (интерфейсы C# могут определять операции!), и указания ограничения интерфейса для обобщенного класса. В любом случае первоначальный обзор построения специальных обобщенных типов завершен. Во время исследования типа делегата в главе 12 мы вновь обратимся к теме обобщений.

Резюме

Глава начиналась с рассмотрения необобщенных типов коллекций в пространствах имен System.Collections и System.Collections.Specialized, включая разнообразные проблемы, которые связаны со многими необобщенными контейнерами, в том числе отсутствие безопасности в отношении типов и накладные расходы времени выполнения в форме операций упаковки и распаковки. Как упоминалось, именно по этим причинам в современных приложениях .NET будут использоваться классы обобщенных коллекций из пространств имен System.Collections.Generic и System.Collections.ObjectModel.

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