Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

ReflectOverQueryResults(subset);

// Вывести результаты.

foreach (string s in subset)

{

  Console.WriteLine("Item: {0}", s);

}

Запустив приложение, легко заметить, что переменная subset в действительности представляет собой экземпляр обобщенного типа OrderedEnumerable<TElement, ТКеу> (представленного в коде CIL как OrderedEnumerable`2), который является внутренним абстрактным типом, находящимся в сборке System.Linq.dll:

***** Info about your query using Query Expressions*****

resultSet is of type: OrderedEnumerable`2

resultSet location: System.Linq

Внесите такое же изменение в код метода QueryOverStringsWithExtensionMethods(), но передав во втором параметре строку "Extension Methods":

// Построить выражение запроса для поиска

// в массиве элементов, содержащих пробел.

IEnumerable<string> subset = currentVideoGames

    .Where(g => g.Contains(" ")) .OrderBy(g => g).Select(g => g);

ReflectOverQueryResults(subset,"Extension Methods");

// Вывести результаты.

foreach (string s in subset)

{

  Console.WriteLine("Item: {0}", s);

}

После запуска приложения выяснится, что переменная subset является экземпляром типа SelectIPartitionIterator. Но если удалить из запроса конструкцию Select(g=>g), то subset снова станет экземпляром типа OrderedEnumerable<TElement, ТКеу>. Что все это значит? Для подавляющего большинства разработчиков немногое (если вообще что-либо). Оба типа являются производными от IEnumerable<T>, проход по ним осуществляется одинаковым образом и они оба способны создавать список или массив своих значений.

***** Info about your query using Extension Methods *****

resultSet is of type: SelectIPartitionIterator`2

resultSet location: System.Linq

LINQ и неявно типизированные локальные переменные

Хотя в приведенной программе относительно легко выяснить, что результирующий набор может быть интерпретирован как перечисление объектов string (например, IEnumerable<string>), тот факт, что подмножество на самом деле имеет тип OrderedEnumerable<TElement, ТКеу>, не настолько ясен.

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

Чтобы еще больше подчеркнуть данное обстоятельство, ниже показан дополнительный вспомогательный метод, определенный внутри класса Program:

static void QueryOverInts()

{

  int[] numbers = {10, 20, 30, 40, 1, 2, 3, 8};

  // Вывести только элементы меньше 10.

  IEnumerable<int> subset = from i in numbers where i < 10 select i;

  foreach (int i in subset)

  {

    Console.WriteLine("Item: {0}", i);

  }

  ReflectOverQueryResults(subset);

}

В рассматриваемом случае переменная subset имеет совершенно другой внутренний тип. На этот раз тип, реализующий интерфейс IEnumerable<int>, представляет собой низкоуровневый класс по имени WhereArrayIterator<T>:

Item: 1

Item: 2

Item: 3

Item: 8

***** Info about your query *****

resultSet is of type: WhereArrayIterator`1

resultSet location: System.Linq

Учитывая, что точный тип запроса LINQ не вполне очевиден, в первых примерах результаты запросов были представлены как переменная IEnumerable<T>, где Т — тип данных в возвращенной последовательности (string, int и т.д.). Тем не менее, ситуация по-прежнему довольно запутана. Чтобы еще больше все усложнить, стоит упомянуть, что поскольку интерфейс IEnumerable<T> расширяет необобщенный IEnumerable, получать результат запроса LINQ допускается и так:

System.Collections.IEnumerable subset =

  from i in numbers

  where i < 10

  select i;

К счастью, неявная типизация при работе с запросами LINQ значительно проясняет картину:

static void QueryOverInts()

{

  int[] numbers = {10, 20, 30, 40, 1, 2, 3, 8};

  // Здесь используется неявная типизация...

  var subset = from i in numbers where i < 10 select i;

  // ...и здесь тоже.

  foreach (var i in subset)

  {

    Console.WriteLine("Item: {0} ", i);

  }

  ReflectOverQueryResults(subset);

}

В качестве эмпирического правила: при захвате результатов запроса LINQ всегда необходимо использовать неявную типизацию. Однако помните, что (в большинстве случаев) действительное возвращаемое значение имеет тип, реализующий интерфейс IEnumerable<T>.

Какой точно тип кроется за ним (OrderedEnumerable<TElement, ТКеу>, WhereArrayIterator<T> и т.п.), к делу не относится, и определять его вовсе не обязательно. Как было показано в предыдущем примере кода, для прохода по извлеченным данным можно просто применить ключевое слово var внутри конструкции foreach.

LINQ и расширяющие методы

Несмотря на то что в текущем примере совершенно не требуется напрямую писать какие-то расширяющие методы, на самом деле они благополучно используются на заднем плане. Выражения запросов LINQ могут применяться для прохода по содержимому контейнеров данных, которые реализуют обобщенный интерфейс IEnumerable<T>. Тем не менее, класс System.Array (используемый для представления массива строк и массива целых чисел) не реализует этот контракт:

// Похоже, что тип System.Array не реализует

// корректную инфраструктуру для выражений запросов!

public abstract class Array : ICloneable, IList,

  IStructuralComparable, IStructuralEquatable

{

  ...

}

Хотя класс System.Array не реализует напрямую интерфейс IEnumerable<T>, он косвенно получает необходимую функциональность данного типа (а также многие другие члены, связанные с LINQ) через статический тип класса System.Linq.Enumerable.

В служебном классе System.Linq.Enumerable определено множество обобщенных расширяющих методов (таких как Aggregate<T>(), First<T>(), Мах<Т>() и т.д.), которые класс System.Array (и другие типы) получают в свое распоряжение на заднем плане. Таким образом, если вы примените операцию точки к локальной переменной currentVideoGames, то обнаружите большое количество членов, которые отсутствуют в формальном определении System.Array. 

Роль отложенного выполнения

Еще один важный момент, касающийся выражений запросов LINQ, заключается в том, что фактически они не оцениваются до тех пор, пока не начнется итерация по результирующей последовательности. Формально это называется отложенным выполнением. Преимущество такого подхода связано с возможностью применения одного и того же запроса LINQ многократно к тому же самому контейнеру и полной гарантией получения актуальных результатов. Взгляните