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

На заметку! В библиотеках базовых классов .NET Core доступны два дополнительных пространства имен, связанные с коллекциями (System.Collections.ObjectModel и System.Collections.Concurrent). Первое из них будет объясняться позже в главе, когда вы освоите тему обобщений. Пространство имен System.Collections.Concurrent предоставляет классы коллекций, хорошо подходящие для многопоточной среды (многопоточность обсуждается в главе 15).

Проблемы, присущие необобщенным коллекциям

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

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

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

Прежде чем вы увидите, как применять обобщения в своих программах, полезно чуть глубже рассмотреть недостатки необобщенных классов коллекций, что поможет лучше понять проблемы, которые был призван решить механизм обобщений. Создайте новый проект консольного приложения по имени IssuesWithNongenericCollections, импортируйте пространства имен System и System.Collections в начале файла Program.cs и удалите оставшийся код:

using System;

using System.Collections;

Проблема производительности

Как уже было указано в главе 4, платформа .NET Core поддерживает две обширные категории данных: типы значений и ссылочные типы. Поскольку в .NET Core определены две основные категории типов, временами возникает необходимость представить переменную одной категории как переменную другой категории. Для этого в C# предлагается простой механизм, называемый упаковкой (boxing), который позволяет хранить данные типа значения внутри ссылочной переменной. Предположим, что в методе по имени SimpleBoxUnboxOperation создана локальная переменная типа int. Если где-то в приложении понадобится представить такой тип значения как ссылочный тип, то значение придется упаковать:

static void SimpleBoxUnboxOperation

{

  // Создать переменную ValueType (int).

  int myInt = 25;

  // Упаковать int в ссылку на object.

  object boxedInt = myInt;

}

Упаковку можно формально определить как процесс явного присваивания данных типа значения переменной System.Object. При упаковке значения среда CoreCLR размещает в куче новый объект и копирует в него величину типа значения (в данном случае 25). В качестве результата возвращается ссылка на вновь размещенный в куче объект.