Когда целесообразнее использовать структуру вместо класса?

Когда использовать структуру вместо класса в C#

Выбор между структурой (struct) и классом (class) в C# — это важное проектировочное решение, влияющее на производительность, семантику и корректность программы. Вот основные критерии, когда структура предпочтительнее класса.

Ключевые критерии использования структур

1. Маленький размер и неделимая логика данных

Структуры должны быть неизменяемыми (immutable) и содержать небольшое количество полей (обычно до 16-24 байт, но это эмпирическое правило). Идеально подходят для представления простых значений.

public struct Point
{
    public int X { get; }
    public int Y { get; }
    
    public Point(int x, int y)
    {
        X = x;
        Y = y;
    }
}

2. Семантика значений (Value Semantics)

Когда необходима копия по значению, а не по ссылке. Изменения копии не должны затрагивать оригинал. Это критично для координат, векторов, цветов.

Point p1 = new Point(5, 10);
Point p2 = p1; // Создается полная копия данных
p2.X = 20;     // p1.X остается 5

3. Частое создание кратковременных объектов в куче (heap)

Структуры хранятся в стеке (stack) или внутри родительского объекта, что уменьшает нагрузку на сборщик мусора (GC). Если создаются миллионы временных объектов (например, в математических вычислениях), struct может дать прирост производительности.

4. Использование в массивах с плотным расположением в памяти

Массивы структур хранятся в непрерывной памяти, что повышает локальность данных (data locality) и ускоряет обход массивов из-за кэш-дружелюбности.

Point[] points = new Point[1000]; 
// Все 1000 Point лежат в массиве последовательно

5. Аргументы методов с модификатором in или ref

Для избежания лишнего копирования больших структур можно использовать in (readonly ref). Это дает контроль над передачей.

public double CalculateDistance(in Point p1, in Point p2)
{
    // Передача по ссылке без копирования, но с гарантией неизменяемости
}

Когда НЕЛЬЗЯ использовать структуры

• Большой размер (> 16-24 байт): копирование становится дорогим.
• Необходимость наследования: struct не поддерживает наследование (кроме интерфейсов).
• Изменяемое состояние: изменяемые struct приводят к ошибкам, особенно при неявном копировании.
• Логика жизненного цикла: если объект должен существовать дольше метода или передаваться по ссылке.

Важные особенности и подводные камни

1. Упаковка (boxing): при приведении struct к интерфейсу или object происходит упаковка в кучу, что снижает производительность.
2. Реализация интерфейсов: struct могут реализовывать интерфейсы, но это часто ведет к упаковке.
3. Модификатор readonly: с C# 7.2 можно объявлять readonly struct для гарантии неизменяемости.
4. Конструкторы без параметров: до C# 10 struct не могли иметь явных конструкторов без параметров. С C# 10 это возможно, но с ограничениями.

Практические примеры из .NET

• System.Int32, System.Double — примитивные типы как struct.
• System.DateTime, System.TimeSpan — представление временных интервалов.
• System.Drawing.Point, System.Drawing.Color — графические примитивы.

Заключение

Структуры — это инструмент для оптимизации производительности и выражения семантики значений. Их использование оправдано для небольших, неизменяемых данных, которые активно создаются и уничтожаются. Однако из-за семантики копирования они требуют аккуратного проектирования. В сомнительных случаях начинайте с класса, переходя к struct только при доказанных требованиях к производительности или необходимости value semantics. Современные возможности C# (readonly struct, ref struct, in параметры) расширяют сценарии использования структур, но и добавляют сложности.