Язык программирования C#9 и платформа .NET5

  Console.WriteLine;
  ReflectOverAnonymousType(firstCar);
  ReflectOverAnonymousType(secondCar);
 }

В результате вызова метода EqualityTest получается несколько неожиданный вывод:

 My car is a Bright Pink Saab.
 You have a Black BMW going 90 MPH
 ToString == { Make = BMW, Color = Black, Speed = 90 }
 Same anonymous object!
 Not the same anonymous object!
 We are both the same type!
 obj is an instance of: <>f__AnonymousType0`3
 Base class of <>f__AnonymousType0`3 is System.Object
 obj.ToString == { Color = Bright Pink, Make = Saab, CurrentSpeed = 55 }
 obj.GetHashCode == -925496951
 obj is an instance of: <>f__AnonymousType0`3
 Base class of <>f__AnonymousType0`3 is System.Object
 obj.ToString == { Color = Bright Pink, Make = Saab, CurrentSpeed = 55 }
 obj.GetHashCode == -925496951

Как видите, первая проверка, где вызывается Equals, возвращает true, и потому на консоль выводится сообщение Same anonymous object! (Тот же самый анонимный объект). Причина в том, что сгенерированный компилятором метод Equals при проверке эквивалентности применяет семантику на основе значений (т.е. проверяет значения каждого поля сравниваемых объектов).

Тем не менее, вторая проверка, в которой используется операция ==, приводит к выводу на консоль строки Not the same anonymous object! (He тот же самый анонимный объект), что на первый взгляд выглядит несколько нелогично. Такой результат обусловлен тем, что анонимные типы не получают перегруженных версий операций проверки равенства (== и !=), поэтому при проверке эквивалентности объектов анонимных типов с применением операций равенства C# (вместо метода Equals) проверяются ссылки, а не значения, поддерживаемые объектами.

Наконец, в финальной проверке (где исследуется имя лежащего в основе типа) обнаруживается, что объекты анонимных типов являются экземплярами одного и того же типа класса, сгенерированного компилятором (f__AnonymousType0`3 в данном примере), т.к. firstCar и secondCar имеют одинаковые наборы свойств (Color, Make и CurrentSpeed).

Это иллюстрирует важный, но тонкий аспект: компилятор будет генерировать новое определение класса, только когда анонимный тип содержит уникальные имена свойств. Таким образом, если вы объявляете идентичные анонимные типы (в смысле имеющие те же самые имена свойств) внутри сборки, то компилятор генерирует единственное определение анонимного типа.

Анонимные типы, содержащие другие анонимные типы

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

 // Создать анонимный тип, состоящий из еще одного анонимного типа.
 var purchaseItem = new {
  TimeBought = DateTime.Now,
  ItemBought = new {Color = "Red", Make = "Saab", CurrentSpeed = 55},
  Price = 34.000};
 ReflectOverAnonymousType(purchaseItem);

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

• Контроль над именами анонимных типов отсутствует.

• Анонимные типы всегда расширяют System.Object.

• Поля и свойства анонимного типа всегда допускают только чтение.

• Анонимные типы не могут поддерживать события, специальные методы, специальные операции или специальные переопределения.

• Анонимные типы всегда неявно запечатаны.

• Экземпляры анонимных типов всегда создаются с применением стандартных конструкторов.

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

Работа с типами указателей

Последняя тема главы касается средства С#, которое в подавляющем большинстве проектов .NET Core применяется реже всех остальных.

На заметку! В последующих примерах предполагается наличие у вас определенных навыков манипулирования указателями в языке C++ . Если это не так, тогда можете спокойно пропустить данную тему. В большинстве приложений C# указатели не используются.

В главе 4 вы узнали, что в рамках платформы .NET Core определены две крупные категории данных: типы значений и ссылочные типы. По правде говоря, на самом деле есть еще и третья категория: типы указателей. Для работы с типами указателей доступны специфичные операции и ключевые слова (табл. 11.2), которые позволяют обойти схему управления памятью исполняющей среды .NET 5 и взять дело в свои руки.

Перед погружением в детали следует еще раз подчеркнуть, что вам очень редко, если вообще когда-нибудь, понадобится использовать типы указателей. Хотя C# позволяет опуститься на уровень манипуляций указателями, помните, что исполняющая среда .NET Core не имеет абсолютно никакого понятия о ваших намерениях. Соответственно, если вы неправильно управляете указателем, то сами и будете отвечать за последствия. С учетом этих предупреждений возникает вопрос: когда в принципе может возникнуть необходимость работы с типами указателей? Существуют две распространенные ситуации.

• Нужно оптимизировать избранные части приложения, напрямую манипулируя памятью за рамками ее управления со стороны исполняющей среды .NET 5.

• Необходимо вызывать методы из DLL-библиотеки, написанной на С, либо из сервера СОМ, которые требуют передачи типов указателей в качестве параметров. Но даже в таком случае часто можно обойтись без применения типов указателей, отдав предпочтение типу System.IntPtr и членам типа System.Runtime.InteropServices.Marshal.