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

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

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

// Создать анонимный тип, состоящий из еще одного анонимного типа.

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.

Если вы решили задействовать данное средство языка С#, тогда придется информировать компилятор C# о своих намерениях, разрешив проекту поддерживать "небезопасный код". Создайте новый проект консольного приложения по имени UnsafeCode и включите поддержку небезопасного кода, добавив в файл UnsafeCode.csproj следующие строки:

  true