Источник, на который ссылается OP, заслуживает доверия ... но как насчет Microsoft - какова позиция по использованию структур? Я искал дополнительные уроки Microsoft, и вот что я нашел:

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

Не определяйте структуру, если тип не обладает всеми следующими характеристиками:

1. Он логически представляет одно значение, подобное примитивным типам (целочисленное, двойное и т. Д.).
2. Он имеет размер экземпляра менее 16 байт.
3. Это непреложно.
4. Его не придется часто ставить в коробку.

Microsoft постоянно нарушает эти правила

Ладно, в любом случае №2 и №3. Наш любимый словарь имеет 2 внутренних структуры:

[StructLayout(LayoutKind.Sequential)]  // default for structs
private struct Entry  //<Tkey, TValue>
{
    //  View code at *Reference Source
}

[Serializable, StructLayout(LayoutKind.Sequential)]
public struct Enumerator : 
    IEnumerator<KeyValuePair<TKey, TValue>>, IDisposable, 
    IDictionaryEnumerator, IEnumerator
{
    //  View code at *Reference Source
}

* Справочный источник

Источник 'JonnyCantCode.com' получил 3 из 4 - вполне простительно, поскольку номер 4, вероятно, не будет проблемой. Если вы обнаружите, что блокируете структуру, переосмыслите свою архитектуру.

Давайте посмотрим, почему Microsoft будет использовать эти структуры:

1. Каждая структура Entry и Enumerator представляет отдельные значения.
2. Скорость
3. Entry никогда не передается как параметр вне класса Dictionary. Дальнейшее исследование показывает, что для реализации IEnumerable Dictionary использует структуру Enumerator, которую он копирует каждый раз, когда запрашивается перечислитель ... имеет смысл.
4. Внутри класса Dictionary. Enumerator является общедоступным, поскольку Dictionary перечислим и должен иметь равную доступность для реализации интерфейса IEnumerator - например, Получатель IEnumerator.

Обновление. Кроме того, имейте в виду, что когда структура реализует интерфейс - как это делает Enumerator - и приводится к этому реализованному типу, структура становится ссылочным типом и перемещается в кучу. Внутри класса Dictionary Enumerator по-прежнему является типом значения. Однако, как только метод вызывает GetEnumerator(), возвращается ссылочный тип IEnumerator.

Чего мы здесь не видим, так это какой-либо попытки или доказательства требования сохранять структуры неизменными или поддерживать размер экземпляра всего 16 байтов или меньше:

1. Ничто в приведенных выше структурах не объявлено readonly - не неизменным.
2. Размер этой структуры может превышать 16 байт.
3. Entry имеет неопределенное время жизни (от Add() до Remove(), Clear() или сборка мусора);

И ... 4. Обе структуры хранят TKey и TValue, которые, как мы все знаем, вполне могут быть ссылочными типами (добавлена ​​дополнительная информация).

Несмотря на хешированные ключи, словари работают быстро, отчасти потому, что создание экземпляров структуры выполняется быстрее, чем ссылочного типа. Здесь у меня Dictionary<int, int>, в котором хранится 300 000 случайных целых чисел с последовательно увеличивающимися ключами.

Емкость: 312874
MemSize: 2660827 байт
Завершенное изменение размера: 5 мс
Общее время заполнения: 889 мс

Емкость: количество доступных элементов до изменения размера внутреннего массива.

MemSize: определяется путем сериализации словаря в MemoryStream и получения байтовой длины (достаточно точной для наших целей).

Завершенное изменение размера: время, необходимое для изменения размера внутреннего массива с 150862 элементов до 312874 элементов. Когда вы думаете, что каждый элемент последовательно копируется через Array.CopyTo(), это не так уж плохо.

Общее время заполнения: предположительно искажено из-за регистрации и OnResize события, которое я добавил в источник; тем не менее, все еще впечатляет заполнение 300k целых чисел при 15-кратном изменении размера во время операции. Просто из любопытства, сколько бы было времени на заполнение, если бы я уже знал емкость? 13 мс

Итак, что, если бы Entry был классом? Неужели эти времена или метрики действительно так сильно различаются?

Емкость: 312874
MemSize: 2660827 байт
Завершенное изменение размера: 26 мс
Общее время заполнения: 964 мс

Очевидно, большая разница в изменении размера. Есть ли разница, если словарь инициализирован с помощью емкости? Недостаточно, чтобы беспокоиться о ... 12 мс.

Происходит следующее: поскольку Entry - это структура, она не требует инициализации, как ссылочный тип. В этом и прелесть, и проклятие ценностного типа. Чтобы использовать Entry в качестве ссылочного типа, мне пришлось вставить следующий код:

/*
 *  Added to satisfy initialization of entry elements --
 *  this is where the extra time is spent resizing the Entry array
 * **/
for (int i = 0 ; i < prime ; i++)
{
    destinationArray[i] = new Entry( );
}
/*  *********************************************** */  

Причину, по которой мне пришлось инициализировать каждый элемент массива Entry в качестве ссылочного типа, можно найти на странице MSDN: Structure Design < / а>. Суммируя:

На самом деле это довольно просто, и мы позаимствуем его из Трех законов робототехники Азимова:

1. Структура должна быть безопасной для использования
2. Структура должна эффективно выполнять свою функцию, если это не нарушит правило №1.
3. Структура должна оставаться нетронутой во время использования, если только ее уничтожение не требуется для выполнения правила №1.

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

Когда бы ты не:

1. не нужен полиморфизм,
2. хотите семантику значений и
3. хотите избежать выделения кучи и связанных накладных расходов на сборку мусора.

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

Я не согласен с правилами, приведенными в исходном посте. Вот мои правила:

1) Вы используете структуры для производительности при хранении в массивах. (см. также Когда строится ответ?)

2) Они нужны вам в коде, передающем структурированные данные в / из C / C ++

3) Не используйте структуры, если они вам не нужны:

• Они ведут себя не так, как «обычные объекты» (ссылочные типы) при назначении и при передаче в качестве аргументов, что может привести к неожиданному поведению; это особенно опасно, если человек, просматривающий код, не знает, что имеет дело со структурой.
• Они не могут передаваться по наследству.
• Передача структур в качестве аргументов дороже классов.

Используйте структуру, если вам нужна семантика значения, а не семантика ссылок.

Edit

Не уверен, почему люди голосуют против этого, но это верный аргумент, и он был сделан до того, как оппонент разъяснил свой вопрос, и он это самая фундаментальная основная причина структуры.

Если вам нужна эталонная семантика, вам нужен класс, а не структура.

В дополнение к ответу «это значение» есть один конкретный сценарий использования структур, когда вы знаете, что у вас есть набор данных, который вызывает проблемы со сборкой мусора, и у вас много предметов. Например, большой список / массив экземпляров Person. Естественная метафора здесь - это класс, но если у вас есть большое количество долгоживущих экземпляров Person, они могут в конечном итоге засорить GEN-2 и вызвать сбои сборки мусора. Если сценарий оправдывает это, одним из возможных подходов является использование массива (а не списка) структур Person, то есть Person[]. Теперь вместо миллионов объектов в GEN-2 у вас есть один фрагмент LOH (я предполагаю, что здесь нет строк и т. Д., Т.е. чистое значение без каких-либо ссылок). Это очень мало влияет на сборщик мусора.

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

int index = ...
int id = peopleArray[index].Id;

Обратите внимание, что сохранение самих значений неизменными здесь поможет. Для более сложной логики используйте метод с параметром by-ref:

void Foo(ref Person person) {...}
...
Foo(ref peopleArray[index]);

Опять же, это на месте - мы не скопировали значение.

В очень специфических сценариях эта тактика может быть очень успешной; тем не менее, это довольно продвинутая scernario, которую следует использовать, только если вы знаете, что делаете и почему. По умолчанию здесь будет класс.

Из спецификации языка C #:

1.7 Структуры

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

Структуры особенно полезны для небольших структур данных, имеющих семантику значений. Комплексные числа, точки в системе координат или пары ключ-значение в словаре - все это хорошие примеры структур. Использование структур вместо классов для небольших структур данных может иметь большое значение в количестве выделений памяти, выполняемых приложением. Например, следующая программа создает и инициализирует массив из 100 точек. Когда Point реализован как класс, создается 101 отдельный объект - один для массива и по одному для 100 элементов.

class Point
{
   public int x, y;

   public Point(int x, int y) {
      this.x = x;
      this.y = y;
   }
}

class Test
{
   static void Main() {
      Point[] points = new Point[100];
      for (int i = 0; i < 100; i++) points[i] = new Point(i, i);
   }
}

Альтернативный вариант - сделать Point структурой.

struct Point
{
   public int x, y;

   public Point(int x, int y) {
      this.x = x;
      this.y = y;
   }
}

Теперь создается только один объект - объект для массива - и экземпляры Point хранятся в массиве в строке.

Конструкторы структуры вызываются с помощью оператора new, но это не означает, что память выделяется. Вместо того, чтобы динамически выделять объект и возвращать ссылку на него, конструктор структуры просто возвращает само значение структуры (обычно во временном месте в стеке), и это значение затем копируется по мере необходимости.

С классами две переменные могут ссылаться на один и тот же объект и, следовательно, операции с одной переменной могут влиять на объект, на который ссылается другая переменная. В структурах каждая переменная имеет свою собственную копию данных, и операции с одной из них не могут повлиять на другую. Например, вывод следующего фрагмента кода зависит от того, является ли Point классом или структурой.

Point a = new Point(10, 10);
Point b = a;
a.x = 20;
Console.WriteLine(b.x);

Если Point является классом, на выходе будет 20, потому что a и b ссылаются на один и тот же объект. Если Point является структурой, на выходе будет 10, потому что присвоение a переменной b создает копию значения, и на эту копию не влияет последующее присвоение a.x.

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

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

Вот основное правило.

• Если все поля-члены являются типами значений, создайте структуру.

• Если какое-либо поле-член является ссылочным типом, создайте класс. Это связано с тем, что поле ссылочного типа в любом случае потребует выделения кучи.

Exmaples

public struct MyPoint 
{
    public int X; // Value Type
    public int Y; // Value Type
}

public class MyPointWithName 
{
    public int X; // Value Type
    public int Y; // Value Type
    public string Name; // Reference Type
}

Во-первых: сценарии взаимодействия или когда вам нужно указать макет памяти

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

Вам необходимо использовать «структуру» в ситуациях, когда вы хотите явно указать макет памяти с помощью StructLayoutAttribute - обычно для PInvoke.

Изменить: комментарий указывает, что вы можете использовать класс или структуру с StructLayoutAttribute, и это, безусловно, правда. На практике вы обычно используете структуру - она ​​выделяется в стеке, а не в куче, что имеет смысл, если вы просто передаете аргумент неуправляемому вызову метода.

Я использую структуры для упаковки или распаковки любого вида двоичного формата связи. Это включает чтение или запись на диск, списки вершин DirectX, сетевые протоколы или работу с зашифрованными / сжатыми данными.

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

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

1. Когда вам нужна семантика копирования.
2. Когда вам нужна автоматическая инициализация, обычно в массивах этих типов.

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

Итак, вывод: будьте осторожны с LINQ и упаковкой / распаковкой скрытых структур, а использование структур для микрооптимизации строго придерживается массивов.

P.S. Другой эталон прохождения структуры / класса через стек вызовов - это https://stackoverflow.com/a/47864451/506147

BenchmarkDotNet=v0.10.8, OS=Windows 10 Redstone 2 (10.0.15063)
Processor=Intel Core i5-2500K CPU 3.30GHz (Sandy Bridge), ProcessorCount=4
Frequency=3233542 Hz, Resolution=309.2584 ns, Timer=TSC
  [Host] : Clr 4.0.30319.42000, 64bit RyuJIT-v4.7.2101.1
  Clr    : Clr 4.0.30319.42000, 64bit RyuJIT-v4.7.2101.1
  Core   : .NET Core 4.6.25211.01, 64bit RyuJIT


          Method |  Job | Runtime |      Mean |     Error |    StdDev |       Min |       Max |    Median | Rank |  Gen 0 | Allocated |
---------------- |----- |-------- |----------:|----------:|----------:|----------:|----------:|----------:|-----:|-------:|----------:|
   TestListClass |  Clr |     Clr |  5.599 us | 0.0408 us | 0.0382 us |  5.561 us |  5.689 us |  5.583 us |    3 |      - |       0 B |
  TestArrayClass |  Clr |     Clr |  2.024 us | 0.0102 us | 0.0096 us |  2.011 us |  2.043 us |  2.022 us |    2 |      - |       0 B |
  TestListStruct |  Clr |     Clr |  8.427 us | 0.1983 us | 0.2204 us |  8.101 us |  9.007 us |  8.374 us |    5 |      - |       0 B |
 TestArrayStruct |  Clr |     Clr |  1.539 us | 0.0295 us | 0.0276 us |  1.502 us |  1.577 us |  1.537 us |    1 |      - |       0 B |
   TestLinqClass |  Clr |     Clr | 13.117 us | 0.1007 us | 0.0892 us | 13.007 us | 13.301 us | 13.089 us |    7 | 0.0153 |      80 B |
  TestLinqStruct |  Clr |     Clr | 28.676 us | 0.1837 us | 0.1534 us | 28.441 us | 28.957 us | 28.660 us |    9 |      - |      96 B |
   TestListClass | Core |    Core |  5.747 us | 0.1147 us | 0.1275 us |  5.567 us |  5.945 us |  5.756 us |    4 |      - |       0 B |
  TestArrayClass | Core |    Core |  2.023 us | 0.0299 us | 0.0279 us |  1.990 us |  2.069 us |  2.013 us |    2 |      - |       0 B |
  TestListStruct | Core |    Core |  8.753 us | 0.1659 us | 0.1910 us |  8.498 us |  9.110 us |  8.670 us |    6 |      - |       0 B |
 TestArrayStruct | Core |    Core |  1.552 us | 0.0307 us | 0.0377 us |  1.496 us |  1.618 us |  1.552 us |    1 |      - |       0 B |
   TestLinqClass | Core |    Core | 14.286 us | 0.2430 us | 0.2273 us | 13.956 us | 14.678 us | 14.313 us |    8 | 0.0153 |      72 B |
  TestLinqStruct | Core |    Core | 30.121 us | 0.5941 us | 0.5835 us | 28.928 us | 30.909 us | 30.153 us |   10 |      - |      88 B |

Код:

[RankColumn, MinColumn, MaxColumn, StdDevColumn, MedianColumn]
    [ClrJob, CoreJob]
    [HtmlExporter, MarkdownExporter]
    [MemoryDiagnoser]
    public class BenchmarkRef
    {
        public class C1
        {
            public string Text1;
            public string Text2;
            public string Text3;
        }

        public struct S1
        {
            public string Text1;
            public string Text2;
            public string Text3;
        }

        List<C1> testListClass = new List<C1>();
        List<S1> testListStruct = new List<S1>();
        C1[] testArrayClass;
        S1[] testArrayStruct;
        public BenchmarkRef()
        {
            for(int i=0;i<1000;i++)
            {
                testListClass.Add(new C1  { Text1= i.ToString(), Text2=null, Text3= i.ToString() });
                testListStruct.Add(new S1 { Text1 = i.ToString(), Text2 = null, Text3 = i.ToString() });
            }
            testArrayClass = testListClass.ToArray();
            testArrayStruct = testListStruct.ToArray();
        }

        [Benchmark]
        public int TestListClass()
        {
            var x = 0;
            foreach(var i in testListClass)
            {
                x += i.Text1.Length + i.Text3.Length;
            }
            return x;
        }

        [Benchmark]
        public int TestArrayClass()
        {
            var x = 0;
            foreach (var i in testArrayClass)
            {
                x += i.Text1.Length + i.Text3.Length;
            }
            return x;
        }

        [Benchmark]
        public int TestListStruct()
        {
            var x = 0;
            foreach (var i in testListStruct)
            {
                x += i.Text1.Length + i.Text3.Length;
            }
            return x;
        }

        [Benchmark]
        public int TestArrayStruct()
        {
            var x = 0;
            foreach (var i in testArrayStruct)
            {
                x += i.Text1.Length + i.Text3.Length;
            }
            return x;
        }

        [Benchmark]
        public int TestLinqClass()
        {
            var x = testListClass.Select(i=> i.Text1.Length + i.Text3.Length).Sum();
            return x;
        }

        [Benchmark]
        public int TestLinqStruct()
        {
            var x = testListStruct.Select(i => i.Text1.Length + i.Text3.Length).Sum();
            return x;
        }
    }

.NET поддерживает value types и reference types (в Java можно определять только ссылочные типы). Экземпляры reference types выделяются в управляемой куче и собираются сборщиком мусора, если на них нет невыполненных ссылок. Экземпляры value types, с другой стороны, выделяются в stack, и, следовательно, выделенная память освобождается, как только их область действия заканчивается. И, конечно же, value types передаются по значению, а reference types по ссылке. Все примитивные типы данных C #, кроме System.String, являются типами значений.

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

В C # structs - это value types, классы - reference types. Вы можете создавать типы значений в C #, используя ключевое слово enum и struct. Использование value type вместо reference type приведет к уменьшению количества объектов в управляемой куче, что приведет к меньшей нагрузке на сборщик мусора (GC), менее частым циклам GC и, следовательно, к повышению производительности. Однако у value types есть и свои недостатки. Передача большого struct определенно дороже, чем передача ссылки, это одна очевидная проблема. Другая проблема - накладные расходы, связанные с boxing/unboxing. Если вам интересно, что означает boxing/unboxing, перейдите по этим ссылкам, чтобы получить хорошее объяснение по boxing и unboxing. Помимо производительности, бывают случаи, когда вам просто нужно, чтобы типы имели семантику значений, что было бы очень сложно (или некрасиво) реализовать, если reference types - это все, что у вас есть. Вы должны использовать только value types, когда вам нужна семантика копирования или автоматическая инициализация, обычно arrays из этих типов.

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

public struct IntStruct {
    public int Value {get; set;}
}

Выполнение следующих действий приводит к 5 экземплярам структуры, хранящейся в памяти:

var struct1 = new IntStruct() { Value = 0 }; // original
var struct2 = struct1;  // A copy is made
var struct3 = struct2;  // A copy is made
var struct4 = struct3;  // A copy is made
var struct5 = struct4;  // A copy is made

// NOTE: A "copy" will occur when you pass a struct into a method parameter.
// To avoid the "copy", use the ref keyword.

// Although structs are designed to use less system resources
// than classes.  If used incorrectly, they could use significantly more.

класс - это ссылочный тип. Когда вы назначаете класс новой переменной, эта переменная содержит ссылку на исходный объект класса.

public class IntClass {
    public int Value {get; set;}
}

Выполнение следующих действий приводит к только одному экземпляру объекта класса в памяти.

var class1 = new IntClass() { Value = 0 };
var class2 = class1;  // A reference is made to class1
var class3 = class2;  // A reference is made to class1
var class4 = class3;  // A reference is made to class1
var class5 = class4;  // A reference is made to class1  

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

var struct1 = new IntStruct() { Value = 0 };
var struct2 = struct1;
struct2.Value = 1;
// At this point, a developer may be surprised when 
// struct1.Value is 0 and not 1

Типы структур в C # или других языках .net обычно используются для хранения вещей, которые должны вести себя как группы значений фиксированного размера. Полезный аспект структурных типов состоит в том, что поля экземпляра структурного типа могут быть изменены путем изменения места хранения, в котором он хранится, и никаким другим способом. Можно закодировать структуру таким образом, чтобы единственный способ изменить любое поле - создать полностью новый экземпляр, а затем использовать назначение структуры для изменения всех полей цели, перезаписав их значениями из нового экземпляра, но если структура не предоставляет средств для создания экземпляра, в котором ее поля имеют значения, отличные от значений по умолчанию, все ее поля будут изменяемыми, если и если сама структура хранится в изменяемом месте.

Обратите внимание, что можно спроектировать тип структуры так, чтобы он по существу вел себя как тип класса, если структура содержит частное поле типа класса и перенаправляет свои собственные члены на член обернутого объекта класса. Например, PersonCollection может предлагать свойства SortedByName и SortedById, оба из которых содержат «неизменяемую» ссылку на PersonCollection (установленную в их конструкторе) и реализуют GetEnumerator путем вызова либо creator.GetNameSortedEnumerator, либо creator.GetIdSortedEnumerator. Такие структуры будут вести себя так же, как ссылка на PersonCollection, за исключением того, что их GetEnumerator методы будут привязаны к разным методам в PersonCollection. Можно также иметь структуру, охватывающую часть массива (например, можно определить структуру ArrayRange<T>, которая будет содержать T[] с именем Arr, int Offset и int Length, с индексированным свойством, которое для индекса idx в диапазоне От 0 до Length-1, будет обращаться к Arr[idx+Offset]). К сожалению, если foo является экземпляром такой структуры, доступным только для чтения, текущие версии компилятора не разрешают такие операции, как foo[3]+=4;, потому что у них нет способа определить, будут ли такие операции пытаться записывать в поля foo.

Также возможно разработать структуру, которая будет вести себя как тип значения, который содержит коллекцию переменного размера (которая будет казаться копируемой всякий раз, когда создается структура), но единственный способ выполнить эту работу - убедиться, что ни один объект, для которого struct содержит ссылку, которая когда-либо будет доступна для всего, что может ее изменить. Например, можно иметь структуру, подобную массиву, которая содержит частный массив, и чей индексированный метод "put" создает новый массив, содержимое которого похоже на исходное, за исключением одного измененного элемента. К сожалению, заставить такие структуры работать эффективно может быть довольно сложно. Хотя бывают случаи, когда семантика структуры может быть удобной (например, возможность передать коллекцию в виде массива в подпрограмму, когда вызывающий и вызываемый оба знают, что внешний код не изменяет коллекцию, это может быть лучше, чем требовать как вызывающего, так и вызываемого. вызываемый для защитного копирования любых данных, которые им передаются), требование, чтобы ссылки на классы указывали на объекты, которые никогда не будут видоизменяться, часто является довольно серьезным ограничением.

Нет, я не совсем согласен с правилами. Это хорошие рекомендации, которые следует учитывать в отношении производительности и стандартизации, но не в свете возможностей.

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

В этом случае я использую классы для представления объектов реального мира в их большей форме, я использую структуры для представления более мелких объектов, которые имеют более точное использование. Как вы это сказали, «более сплоченное целое». Ключевое слово связное. Классы будут более объектно-ориентированными элементами, тогда как структуры могут иметь некоторые из этих характеристик, хотя и в меньшем масштабе. ИМО.

Я часто использую их в тегах Treeview и Listview, где можно очень быстро получить доступ к обычным статическим атрибутам. Я всегда изо всех сил пытался получить эту информацию по-другому. Например, в своих приложениях баз данных я использую Treeview, где у меня есть таблицы, SP, функции или любые другие объекты. Я создаю и заполняю свою структуру, помещаю ее в тег, вытаскиваю, получаю данные выделения и так далее. Я бы не стал так поступать с классом!

Я действительно стараюсь, чтобы они были небольшими, использую их в единичных случаях и не допускаю их изменения. Разумно знать о памяти, распределении и производительности. А тестирование так необходимо.

МИФ №1: КОНСТРУКЦИИ - ЛЕГКИЕ КЛАССЫ

Этот миф принимает самые разные формы. Некоторые люди считают, что типы значений не могут или не должны иметь методов или другого значимого поведения - их следует использовать как простые типы передачи данных, только с общедоступными полями или простыми свойствами. Тип DateTime является хорошим контрпримером к этому: имеет смысл, чтобы он был типом значения, с точки зрения того, что он является фундаментальной единицей, такой как число или символ, а также имеет смысл, чтобы он мог выполнять вычисления на основе его ценность. С другой стороны, типы передачи данных в любом случае должны быть ссылочными типами - решение должно основываться на семантике желаемого значения или ссылочного типа, а не на простоте типа. Другие считают, что типы значений «легче», чем ссылочные типы, с точки зрения производительности. Правда в том, что в некоторых случаях типы значений более производительны - они не требуют сборки мусора, если они не упакованы в коробку, не имеют накладных расходов на идентификацию типа и, например, не требуют разыменования. Но в остальном ссылочные типы более производительны - передача параметров, присвоение значений переменным, возврат значений и аналогичные операции требуют для копирования только 4 или 8 байтов (в зависимости от того, используете ли вы 32-разрядную или 64-разрядную среду CLR. ) вместо копирования всех данных. Представьте себе, если бы ArrayList был каким-то образом «чистым» типом значения и передача выражения ArrayList методу включала копирование всех его данных! Почти во всех случаях производительность на самом деле не определяется таким решением. Узкие места почти никогда не возникают там, где вы думаете, и прежде чем принимать дизайнерское решение на основе производительности, вы должны оценить различные варианты. Стоит отметить, что сочетание этих двух убеждений также не работает. Не имеет значения, сколько методов имеет тип (будь то класс или структура) - это не влияет на память, занимаемую каждым экземпляром. (Существует стоимость памяти, занимаемой для самого кода, но это происходит один раз, а не для каждого экземпляра.)

МИФ № 2: СПРАВОЧНЫЕ ТИПЫ ЖИВЮТ НА КУЧЕ; ТИПЫ ЦЕННОСТЕЙ, ЖИВУЩИЕ В СТЕКЕ

Это часто вызвано ленью со стороны человека, повторяющего его. Первая часть верна - экземпляр ссылочного типа всегда создается в куче. Это вторая часть, которая вызывает проблемы. Как я уже отмечал, значение переменной живет везде, где оно объявлено, поэтому, если у вас есть класс с переменной экземпляра типа int, значение этой переменной для любого данного объекта всегда будет там, где находятся остальные данные для объекта - в куче. В стеке хранятся только локальные переменные (переменные, объявленные внутри методов) и параметры методов. В C # 2 и более поздних версиях даже некоторые локальные переменные на самом деле не хранятся в стеке, как вы увидите, когда мы рассмотрим анонимные методы в главе 5. Актуальны ли эти концепции сейчас? Можно утверждать, что если вы пишете управляемый код, вы должны позволить среде выполнения беспокоиться о том, как лучше всего использовать память. Действительно, спецификация языка не дает никаких гарантий относительно того, что и где живет; будущая среда выполнения может создавать некоторые объекты в стеке, если знает, что это может сойти с рук, или компилятор C # может сгенерировать код, который практически не использует стек. Следующий миф - это обычно просто вопрос терминологии.

МИФ № 3: ОБЪЕКТЫ ПЕРЕДАЮТСЯ ПО ССЫЛКЕ В C # ПО УМОЛЧАНИЮ

Это, наверное, самый распространенный миф. Опять же, люди, которые делают это утверждение часто (хотя и не всегда), знают, как на самом деле ведет себя C #, но они не знают, что на самом деле означает «передача по ссылке». К сожалению, это сбивает с толку людей, которые действительно знают, что это значит. Формальное определение передачи по ссылке относительно сложно, включая l-значения и аналогичную терминологию в области компьютерных наук, но важно то, что если вы передаете переменную по ссылке, метод, который вы вызываете, может изменить значение переменной вызывающего. изменяя значение его параметра. Теперь помните, что значение переменной ссылочного типа - это ссылка, а не сам объект. Вы можете изменить содержимое объекта, на который ссылается параметр, без передачи самого параметра по ссылке. Например, следующий метод изменяет содержимое рассматриваемого объекта StringBuilder, но выражение вызывающего по-прежнему будет относиться к тому же объекту, что и раньше:

void AppendHello(StringBuilder builder)
{
    builder.Append("hello");
}

При вызове этого метода значение параметра (ссылка на StringBuilder) передается по значению. Если бы вы изменили значение переменной конструктора в методе, например, с помощью оператора builder = null;, это изменение не было бы замечено вызывающим, вопреки мифу. Интересно отметить, что неточен не только бит мифа «по ссылке», но и бит «объекты переданы». Сами объекты никогда не передаются ни по ссылке, ни по значению. Когда задействован ссылочный тип, либо переменная передается по ссылке, либо значение аргумента (ссылка) передается по значению. Помимо всего прочего, это отвечает на вопрос о том, что происходит, когда null используется в качестве аргумента по значению - если бы объекты передавались, это могло бы вызвать проблемы, поскольку не было бы объекта для передачи! Вместо этого пустая ссылка передается по значению так же, как и любая другая ссылка. Если это быстрое объяснение вас сбило с толку, возможно, вам стоит взглянуть на мою статью «Передача параметров в C #» (http://mng.bz/otVt), в котором содержится более подробная информация. Эти мифы - не единственные. Бокс и распаковка вносят свою лепту в недоразумения, которые я постараюсь прояснить позже.

Ссылка: C # в подробностях, 3-е издание, Джон Скит

Мое правило

1. Всегда используйте класс;

2. Если есть какие-либо проблемы с производительностью, я пытаюсь изменить какой-либо класс на структуру в зависимости от правил, упомянутых @IAbstract, а затем провожу тест, чтобы увидеть, могут ли эти изменения улучшить производительность.

Класс - это ссылочный тип. Когда объект класса создается, переменная, которой назначается объект, содержит только ссылку на эту память. Когда ссылка на объект присваивается новой переменной, новая переменная ссылается на исходный объект. Изменения, внесенные с помощью одной переменной, отражаются в другой переменной, потому что они оба относятся к одним и тем же данным. Структура - это тип значения. Когда структура создается, переменная, которой назначается структура, содержит фактические данные структуры. Когда структура назначается новой переменной, она копируется. Таким образом, новая переменная и исходная переменная содержат две отдельные копии одних и тех же данных. Изменения, внесенные в одну копию, не влияют на другую копию. Как правило, классы используются для моделирования более сложного поведения или данных, которые должны быть изменены после создания объекта класса. Структуры лучше всего подходят для небольших структур данных, содержащих в основном данные, которые не предназначены для изменения после создания структуры.

Классы и структуры (Руководство по программированию на C #)

Я как раз имел дело с именованным каналом Windows Communication Foundation [WCF] и заметил, что имеет смысл использовать структуры, чтобы гарантировать, что обмен данными имеет тип значения, а не ссылку тип.

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

Итак, вам следует использовать структуры, когда вы хотите представить более простые структуры данных, и особенно если вы знаете, что вы будете создавать экземпляры многих из них. В платформе .NET есть множество примеров, в которых Microsoft использовала структуры вместо классов, например структуру Point, Rectangle и Color.

Вкратце, используйте struct, если:

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

2. свойства и поля в вашем объекте относятся к типу значений, и они не такие большие.

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

Я думаю, что хорошее первое приближение - «никогда».

Я думаю, что хорошее второе приближение - «никогда».

Если вы отчаянно нуждаетесь в производительности, учитывайте их, но всегда измеряйте.

Struct можно использовать для повышения производительности сборки мусора. Хотя обычно вам не нужно беспокоиться о производительности сборщика мусора, есть сценарии, в которых она может быть убийственной. Как большие кеши в приложениях с малой задержкой. См. Этот пост для примера:

http://00sharp.wordpress.com/2013/07/03/a-case-for-the-struct/

Я редко использую структуру для вещей. Но это только я. Это зависит от того, нужен ли мне объект, допускающий значение NULL, или нет.

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

Ниже приведены правила, определенные на веб-сайте Microsoft:

✔️ РАССМАТРИВАЙТЕ определение структуры вместо класса, если экземпляры типа небольшие и обычно недолговечны или обычно встраиваются в другие объекты.

❌ ИЗБЕГАЙТЕ определения структуры, если тип не обладает всеми следующими характеристиками:

Он логически представляет одно значение, аналогично примитивным типам (int, double и т. Д.).

Он имеет размер экземпляра менее 16 байт.

Это непреложно.

Его не придется часто ставить в коробку.

для дальнейшего чтение

Позвольте мне добавить еще один аспект, помимо часто упоминаемой разницы в производительности, и это намерение раскрыть использование значений по умолчанию.

Не используйте структуру, если значения ее полей по умолчанию не представляют разумное значение по умолчанию моделируемой концепции.

Eg.

• Цвет или Точка имеют смысл, даже если для всех их полей установлены значения по умолчанию. RGB 0,0,0 - идеальный цвет, как и (0,0) как точка в 2D.
• Но Address или PersonName не имеют разумного значения по умолчанию. Я имею в виду, можете ли вы понять PersonName, у которого FirstName = null и LastName = null?

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

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

(Обычное заявление об отказе от ответственности: соображения производительности могут перекрыть этот совет. Если у вас есть проблемы с производительностью, всегда измеряйте, прежде чем принимать решение. Попробуйте BenchmarkDotNet, это круто!)

✔️ УЧИТЫВАЙТЕ использование структуры

1. Создайте объект или не нужно создавать объект (напрямую вы можете назначать значения, он создает объект)
2. Need Speed ​​или улучшение производительности
3. Нет необходимости в конструкторах и дестракторах (доступен статический подрядчик)
4. Нет необходимости в наследовании классов, но интерфейсы приемлемы
5. Работа с небольшими объектами рабочей нагрузки, если она станет высокой, возникнет проблема с памятью.
6. Вы не можете использовать значения по умолчанию для переменных.
7. Struct также доступны методы, события, статические конструкторы, переменные и т. Д.
8. Меньше нагрузки на сборщик мусора
9. Нет необходимости в ссылочных типах, только тип значения (каждый раз, когда вы создаете новый объект)
10. Нет неизменяемого объекта (строка является неизменяемым объектом, потому что любая операция не возвращает каждый раз новую строку без изменения оригинала)

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