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

Используйте структуру, если вам нужна семантика типа значения вместо ссылочного типа. Структуры копируются по значению, поэтому будьте осторожны!

Также см. Предыдущие вопросы, например

В чем разница между структурой и классом в .NET?

когда вам действительно не нужно поведение, но вам нужно больше структуры, чем простой массив или словарь.

Следовать за Так я думаю о структурах в целом. Я знаю, что у них могут быть методы, но мне нравится сохранять это общее умственное различие.

Как сказал @Simon, структуры обеспечивают семантику «типа значения», поэтому, если вам нужно поведение, аналогичное встроенному типу данных, используйте структуру. Поскольку структуры передаются по копии, вы хотите убедиться, что они имеют небольшой размер, около 16 байт.

Я бы использовал структуры, когда:

1. объект должен быть доступен только для чтения (каждый раз, когда вы передаете / назначаете структуру, она копируется). Объекты, доступные только для чтения, отлично подходят для многопоточной обработки, поскольку в большинстве случаев они не требуют блокировки.

2. объект маленький и недолговечный. В таком случае велика вероятность того, что объект будет размещен в стеке, что намного эффективнее, чем размещение его в управляемой куче. Более того, память, выделенная объектом, будет освобождена, как только она выйдет за пределы его области видимости. Другими словами, сборщик мусора работает меньше, а память используется более эффективно.

У MSDN есть ответ: Выбор между классами и структурами.

По сути, эта страница дает вам контрольный список из 4 пунктов и предлагает использовать класс, если ваш тип не соответствует всем критериям.

Do not define a structure unless the type has all of the following characteristics:

• It logically represents a single value, similar to primitive types (integer, double, and so on).
• It has an instance size smaller than 16 bytes.
• It is immutable.
• It will not have to be boxed frequently.

Я всегда использовал структуру, когда хотел сгруппировать несколько значений для передачи вещей обратно из вызова метода, но мне не нужно будет использовать ее для чего-либо после того, как я прочитал эти значения. Просто как способ содержать вещи в чистоте. Я склонен рассматривать вещи в структуре как «одноразовые», а вещи в классе как более полезные и «функциональные».

Хм...

Я бы не стал использовать сборку мусора в качестве аргумента за / против использования структур и классов. Управляемая куча работает во многом как стек - создание объекта просто помещает его в верхнюю часть кучи, что почти так же быстро, как и выделение в стеке. Кроме того, если объект недолговечен и не переживает цикл сборщика мусора, освобождение сборщика мусора осуществляется бесплатно, поскольку сборщик мусора работает только с доступной памятью. (Поищите в MSDN, там есть серия статей по управлению памятью .NET, мне просто лень их искать).

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

В любом случае, эти четыре пункта в опубликованной выше статье MSDN кажутся хорошим ориентиром.

Я удивлен, что не прочитал ни одного из предыдущих ответов, которые я считаю наиболее важным аспектом:

Я использую структуры, когда мне нужен тип без идентичности. Например, 3D-точка:

public struct ThreeDimensionalPoint
{
    public readonly int X, Y, Z;
    public ThreeDimensionalPoint(int x, int y, int z)
    {
        this.X = x;
        this.Y = y;
        this.Z = z;
    }

    public override string ToString()
    {
        return "(X = " + this.X + ", Y = " + this.Y + ", Z = " + this.Z + ")";
    }

    public override int GetHashCode()
    {
        return (this.X + 2) ^ (this.Y + 2) ^ (this.Z + 2);
    }

    public override bool Equals(object obj)
    {
        if (!(obj is ThreeDimensionalPoint))
            return false;
        ThreeDimensionalPoint other = (ThreeDimensionalPoint)obj;
        return this == other;
    }

    public static bool operator ==(ThreeDimensionalPoint p1, ThreeDimensionalPoint p2)
    {
        return p1.X == p2.X && p1.Y == p2.Y && p1.Z == p2.Z;
    }

    public static bool operator !=(ThreeDimensionalPoint p1, ThreeDimensionalPoint p2)
    {
        return !(p1 == p2);
    }
}

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

У Билла Вагнера есть глава об этом в своей книге «Эффективный C#» (http://www.amazon.com/Effective-Specific-Ways-Improve-Your/dp/0321245660). В заключение он использует следующий принцип:

1. Is the main responsability of the type data storage?
2. Is its public interface defined entirely by properties that access or modify its data members?
3. Are you sure your type will never have subclasses?
4. Are you sure your type will never be treated polymorphically?

If you answer 'yes' to all 4 questions: use a struct. Otherwise, use a class.

Если сущность будет неизменной, вопрос о том, использовать ли структуру или класс, обычно будет связан с производительностью, а не с семантикой. В 32/64-битной системе для хранения ссылок на классы требуется 4/8 байтов, независимо от количества информации в классе; для копирования ссылки на класс потребуется скопировать 4/8 байта. С другой стороны, каждый экземпляр класса отчетливый будет иметь 8/16 байт служебных данных в дополнение к информации, которую он хранит, и стоимости памяти для ссылок на него. Предположим, вам нужен массив из 500 объектов, каждая из которых содержит четыре 32-битных целых числа. Если объект является структурным типом, массиву потребуется 8000 байт независимо от того, все ли 500 объектов идентичны, все разные или что-то среднее между ними. Если объект относится к классу, массив из 500 ссылок займет 4000 байтов. Если все эти ссылки указывают на разные объекты, для каждого объекта потребуются дополнительные 24 байта (12 000 байтов для всех 500), всего 16 000 байтов - вдвое больше, чем стоимость хранения для типа структуры. С другой стороны, код создал один экземпляр объекта, а затем скопировал ссылку на все 500 слотов массива, общая стоимость составила бы 24 байта для этого экземпляра и 4000 для массива - всего 4024 байта. Значительная экономия. Немногие ситуации будут работать так же хорошо, как предыдущая, но в некоторых случаях может быть возможно скопировать некоторые ссылки на достаточное количество слотов массива, чтобы сделать такое совместное использование целесообразным.

Если объект должен быть изменяемым, вопрос о том, использовать ли класс или структуру, в некотором смысле проще. Предположим, что «Thing» - это структура или класс, у которого есть целочисленное поле с именем x, и выполняется следующий код:

  Thing t1,t2;
  ...
  t2 = t1;
  t2.x = 5;

Кто-то хочет, чтобы последнее утверждение повлияло на t1.x?

Если Thing является типом класса, t1 и t2 будут эквивалентны, то есть t1.x и t2.x также будут эквивалентны. Таким образом, второй оператор повлияет на t1.x. Если Thing является структурным типом, t1 и t2 будут разными экземплярами, то есть t1.x и t2.x будут относиться к разным целым числам. Таким образом, второй оператор не повлияет на t1.x.

Изменяемые структуры и изменяемые классы имеют принципиально разное поведение, хотя .net имеет некоторые особенности в обработке структурных мутаций. Если кому-то нужно поведение типа значения (это означает, что «t2 = t1» будет копировать данные из t1 в t2, оставляя t1 и t2 как отдельные экземпляры), и если можно жить с причудами в обработке типов значений .net, используйте структура. Если кому-то нужна семантика типа значения, но причуды .net могут привести к нарушению семантики типа значения в приложении, используйте класс и бормотайте.

В дополнение к отличным ответам выше:

Структуры - это типы значений.

Они никогда не могут быть установлены на Ничего.

Установка структуры = Nothing установит для всех ее типов значений значения по умолчанию.

Структуры находятся в стеке, а не в куче, поэтому они потокобезопасны и должны использоваться при реализации шаблона объекта передачи, вы никогда не хотите использовать объекты в куче, они являются изменчивыми, в этом случае вы хотите использовать стек вызовов, это базовый случай использования структуры, я удивлен всеми вариантами ответов здесь,

Используйте класс, если:

• Его личность важна. Структуры копируются неявно при передаче по значению в метод.
• У него будет большой объем памяти.
• Его поля нуждаются в инициализаторах.
• Вам нужно унаследовать от базового класса.
• Вам нужно полиморфное поведение;

Используйте структуру, если:

• Он будет действовать как примитивный тип (int, long, byte и т. д.).
• Он должен иметь небольшой объем памяти.
• Вы вызываете метод P / Invoke, который требует передачи структуры ценить.
• Вам необходимо уменьшить влияние сборки мусора на производительность приложения.
• Его поля необходимо инициализировать только значениями по умолчанию. Это значение будет равно нулю для числовых типов, false для логических типов и null для ссылочных типов.
  • Обратите внимание, что в структурах C# 6.0 может быть конструктор по умолчанию, который можно использовать для инициализации поля структуры к значениям, отличным от значений по умолчанию.
• Вам не нужно наследовать от базового класса (кроме ValueType, от которого все структуры наследуются).
• Полиморфное поведение не требуется.

Я думаю, что лучший ответ - просто использовать структуру, когда вам нужен набор свойств, класс, когда это набор свойств И поведения.

Это старая тема, но я хотел предоставить простой тест производительности.

Я создал два файла .cs:

public class TestClass
{
    public long ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

и

public struct TestStruct
{
    public long ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Запустить тест:

• Создать 1 TestClass
• Создать 1 TestStruct
• Создать 100 TestClass
• Создать 100 TestStruct
• Создать 10000 TestClass
• Создать 10000 TestStruct

Полученные результаты:

BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60GHz (Kaby Lake R), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.1.101
[Host]     : .NET Core 3.1.1 (CoreCLR 4.700.19.60701, CoreFX 4.700.19.60801), X64 RyuJIT  [AttachedDebugger]
DefaultJob : .NET Core 3.1.1 (CoreCLR 4.700.19.60701, CoreFX 4.700.19.60801), X64 RyuJIT


|         Method |           Mean |         Error |        StdDev |     Ratio | RatioSD | Rank |    Gen 0 | Gen 1 | Gen 2 | Allocated |
|--------------- |---------------:|--------------:|--------------:|----------:|--------:|-----:|---------:|------:|------:|----------:|

|      UseStruct |      0.0000 ns |     0.0000 ns |     0.0000 ns |     0.000 |    0.00 |    1 |        - |     - |     - |         - |
|       UseClass |      8.1425 ns |     0.1873 ns |     0.1839 ns |     1.000 |    0.00 |    2 |   0.0127 |     - |     - |      40 B |
|   Use100Struct |     36.9359 ns |     0.4026 ns |     0.3569 ns |     4.548 |    0.12 |    3 |        - |     - |     - |         - |
|    Use100Class |    759.3495 ns |    14.8029 ns |    17.0471 ns |    93.144 |    3.24 |    4 |   1.2751 |     - |     - |    4000 B |
| Use10000Struct |  3,002.1976 ns |    25.4853 ns |    22.5920 ns |   369.664 |    8.91 |    5 |        - |     - |     - |         - |
|  Use10000Class | 76,529.2751 ns | 1,570.9425 ns | 2,667.5795 ns | 9,440.182 |  346.76 |    6 | 127.4414 |     - |     - |  400000 B |