Після обговорень тут на SO я вже кілька разів читав зауваження, що змінні структури є «злими» (як у відповіді на це запитання ).

Яка актуальна проблема з мутабельністю та структурами в C #?

Структури - це типи значень, тобто вони копіюються, коли передаються навколо.

Отже, якщо ви змінюєте копію, ви змінюєте лише цю копію, а не оригінал, а не інші копії, які можуть бути навколо.

Якщо ваша структура незмінна, то всі автоматичні копії, отримані в результаті передачі за значенням, будуть однаковими.

Якщо ви хочете змінити це, ви повинні свідомо зробити це, створивши новий екземпляр структури зі зміненими даними. (не копія)

З чого почати ;-p

Блог Еріка Ліпперта завжди корисний для цитати:

Це ще одна причина, по якій змінні типи значень є злими. Намагайтеся завжди робити цінні типи незмінними.

По-перше, ви, як правило, втрачаєте зміни досить легко ... наприклад, вилучаючи речі зі списку:

Foo foo = list[0];
foo.Name = "abc";

що це змінило? Нічого корисного ...

Те саме з властивостями:

myObj.SomeProperty.Size = 22; // the compiler spots this one

змушує вас робити:

Bar bar = myObj.SomeProperty;
bar.Size = 22;
myObj.SomeProperty = bar;

менш критично, існує проблема розміру; об'єкти, що змінюються, мають тенденцію до декількох властивостей; але якщо у вас є структура з двома ints, a string, a DateTimeі a bool, ви можете дуже швидко записати багато пам'яті. З класом декілька абонентів можуть ділитися посиланням на один і той же екземпляр (посилання невеликі).

Я б не сказав, що зло, але незмінність часто є ознакою надмірної готовності програміста, щоб забезпечити максимум функціональності. Насправді це часто не потрібно, а це, в свою чергу, робить інтерфейс меншим, простішим у використанні та складнішим для неправильного використання (= більш надійним).

Одним із прикладів цього є конфлікти читання / запису та запису / запису в гоночних умовах. Вони просто не можуть зустрічатися в незмінних структурах, оскільки запис не є дійсною операцією.

Крім того, я стверджую, що незмінність практично ніколи не потрібна , програміст просто думає, що це може бути в майбутньому. Наприклад, змінити дату просто не має сенсу. Скоріше, створіть нову дату, виходячи зі старої. Це дешева операція, тому продуктивність не враховує.

Змінні структури не є злими.

Вони абсолютно необхідні в умовах високої продуктивності. Наприклад, коли лінії кеш-пам'яті та / або збирання сміття стають вузьким місцем.

Я б не назвав використання незмінної структури в цих цілком справедливих випадках використання "злом".

Я можу бачити, що синтаксис C # не допомагає розрізнити доступ члена типу значення або референтного типу, тому я все для того , щоб віддати перевагу незмінним структурам, що забезпечують незмінність, над змінними структурами.

Однак, замість того, щоб просто позначати непорушні структури як «злі», я б радив обійняти мову та відстоювати більш корисне та конструктивне правило великих пальців.

Наприклад: "структури - це типи значень, які скопіюються за замовчуванням. Вам потрібна посилання, якщо ви не хочете їх копіювати" або "спробуйте спочатку працювати з структурами для читання" .

Структури з загальнодоступними зміненими полями або властивостями не є злими.

Методи структури (на відміну від установників властивостей), які мутують "це", є дещо злими, лише тому, що .net не забезпечує способів відрізнити їх від методів, яких немає. Методи структури, які не мутують "це", повинні бути використані навіть на структурах, які мають лише читання, без необхідності захисного копіювання. Методи, які мутують "це", взагалі не повинні використовуватися в структурах лише для читання. Оскільки .net не хоче забороняти методам структури, які не змінюють "це", не викликати в структурах лише для читання, але не хоче дозволити мутувати структури лише для читання, він захисно копіює структури в " лише контексти, мабуть, отримуючи найгірше з обох світів.

Незважаючи на проблеми з поводженням з методами самовиключення в контекстах, доступних лише для читання, змінні структури часто пропонують семантику, що набагато перевершує типи класів, що змінюються. Розглянемо наступні три методи підпису:

struct PointyStruct {public int x, y, z;};
клас PointyClass {public int x, y, z;};

недійсний метод1 (Foot PointyStruct);
недійсний метод2 (ref PointyyStruct foo);
недійсний метод3 (PointyClass foo);

Для кожного методу дайте відповідь на наступні питання:

1. Якщо припустити, що метод не використовує жодного "небезпечного" коду, він може змінити foo?
2. Якщо до виклику методу не існує зовнішніх посилань на 'foo', чи може після цього існувати зовнішня посилання?

_{Відповіді:}

Запитання 1::
  Method1()ні (чіткий намір)
  Method2() : так (чіткий намір)
  Method3() : так (невизначений намір)
Питання 2
  Method1():: ні
  Method2(): ні (якщо не небезпечно)
  Method3() : так

Метод1 не може змінювати foo і ніколи не отримує посилання. Метод2 отримує короткочасне посилання на foo, який може використовувати модифікувати поля foo будь-яку кількість разів у будь-якому порядку, поки він не повернеться, але він не може зберегти це посилання. Перед тим, як Method2 повернеться, якщо він не використовує небезпечний код, будь-яка та всі копії, які могли бути зроблені з його "foo", зникнуть. Method3, на відміну від Method2, отримує незрозумілу посилання на foo, і немає жодної інформації про те, що це може зробити з цим. Він може взагалі не змінювати foo, він може змінювати foo, а потім повертатися, або він може давати посилання на foo на інший потік, який може мутувати його якось довільним чином у якийсь довільний майбутній час.

Масиви структур пропонують чудову семантику. З огляду на RectArray [500] типу Rectangle, зрозуміло і очевидно, як, наприклад, скопіювати елемент 123 в елемент 456, а потім через деякий час встановити ширину елемента 123 на 555, не порушуючи елемент 456. "RectArray [432] = RectArray [321 ]; ...; RectArray [123]. Ширина = 555; ". Знаючи, що Прямокутник - це структура з цілим полем під назвою Ширина, скаже все, що потрібно знати про вищезазначені твердження.

Тепер припустимо, що RectClass був класом з тими ж полями, що і Rectangle, і один хотів виконувати ті самі операції на RectClassArray [500] типу RectClass. Можливо, масив повинен містити 500 попередньо ініціалізованих незмінних посилань на змінні об'єкти RectClass. у цьому випадку правильний код буде чимось на зразок "RectClassArray [321] .SetBounds (RectClassArray [456]); ...; RectClassArray [321] .X = 555;". Можливо, у масиві передбачається наявність примірників, які не збираються змінювати, тому власний код буде більше схожий на "RectClassArray [321] = RectClassArray [456]; ...; RectClassArray [321] = Новий RectClass (RectClassArray [321 ]); RectClassArray [321] .X = 555; " Щоб знати, що потрібно робити, треба було б знати набагато більше і про RectClass (наприклад, чи підтримує він конструктор копій, метод копіювання з тощо. ) та призначене використання масиву. Ніде не так чисто, як використання структури.

Для переконання, на жаль, немає жодного приємного способу для будь-якого класу контейнерів, крім масиву, запропонувати чисту семантику структури масиву. Найкраще, що можна зробити, якби хотілося, щоб колекція індексувалася, наприклад, рядком, ймовірно, було б запропонувати загальний метод "ActOnItem", який би прийняв рядок для індексу, загального параметра та делегата, який буде переданий шляхом посилання як на загальний параметр, так і на предмет колекції. Це дозволило б отримати майже ту саму семантику, що і масиви stru, але якщо тільки vb.net та C # люди не можуть переслідувати запропонувати хороший синтаксис, код буде чітко виглядає, навіть якщо він має досить ефективні дії (передаючи загальний параметр дозволяють використовувати статичний делегат і уникають необхідності створювати будь-які екземпляри тимчасового класу).

Особисто я підглядаю ненависть до Еріка Ліпперта та ін. spew щодо змінних типів значень. Вони пропонують набагато більш чисту семантику, ніж розбещені типи посилань, які використовуються всюди. Незважаючи на деякі обмеження з підтримкою .net для типів значень, є багато випадків, коли типи змінних значень краще підходять, ніж будь-який інший тип сутності.

Ціннісні типи в основному представляють незмінні поняття. Fx, немає сенсу мати таке математичне значення, як ціле число, вектор тощо, а потім мати змогу змінювати його. Це було б як перевизначення значення цінності. Замість зміни типу значення має більше сенсу присвоїти інше унікальне значення. Подумайте про те, що типи значень порівнюються, порівнюючи всі значення його властивостей. Справа в тому, що якщо властивості однакові, то це те саме універсальне подання цієї величини.

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

Сподіваємось, це має для вас сенс. Безперечно, це більше про концепцію, яку ви намагаєтеся зафіксувати типовими значеннями, ніж практичні деталі.

Є ще кілька інших кутових випадків, які можуть призвести до непередбачуваної поведінки з точки зору програміста.

Типи змінних значень та поля, які читаються тільки

    // Simple mutable structure. 
    // Method IncrementI mutates current state.
    struct Mutable
    {
        public Mutable(int i) : this() 
        {
            I = i;
        }

        public void IncrementI() { I++; }

        public int I { get; private set; }
    }

    // Simple class that contains Mutable structure
    // as readonly field
    class SomeClass 
    {
        public readonly Mutable mutable = new Mutable(5);
    }

    // Simple class that contains Mutable structure
    // as ordinary (non-readonly) field
    class AnotherClass 
    {
        public Mutable mutable = new Mutable(5);
    }

    class Program
    {
        void Main()
        {
            // Case 1. Mutable readonly field
            var someClass = new SomeClass();
            someClass.mutable.IncrementI();
            // still 5, not 6, because SomeClass.mutable field is readonly
            // and compiler creates temporary copy every time when you trying to
            // access this field
            Console.WriteLine(someClass.mutable.I);

            // Case 2. Mutable ordinary field
            var anotherClass = new AnotherClass();
            anotherClass.mutable.IncrementI();

            // Prints 6, because AnotherClass.mutable field is not readonly
            Console.WriteLine(anotherClass.mutable.I);
        }
    }

Типи та масив змінних значень

Припустимо, у нас є масив нашої Mutableструктури, і ми викликаємо IncrementIметод для першого елемента цього масиву. Якої поведінки ви очікуєте від цього дзвінка? Чи слід змінювати значення масиву або лише копію?

    Mutable[] arrayOfMutables = new Mutable[1];
    arrayOfMutables[0] = new Mutable(5);

    // Now we actually accessing reference to the first element
    // without making any additional copy
    arrayOfMutables[0].IncrementI();

    // Prints 6!!
    Console.WriteLine(arrayOfMutables[0].I);

    // Every array implements IList<T> interface
    IList<Mutable> listOfMutables = arrayOfMutables;

    // But accessing values through this interface lead
    // to different behavior: IList indexer returns a copy
    // instead of an managed reference
    listOfMutables[0].IncrementI(); // Should change I to 7

    // Nope! we still have 6, because previous line of code
    // mutate a copy instead of a list value
    Console.WriteLine(listOfMutables[0].I);

Отже, змінні структури не є злими, якщо ви та інша команда чітко розумієте, що ви робите. Але є занадто багато випадкових випадків, коли поведінка програми буде відрізнятися від очікуваного, що може призвести до складних помилок та важко зрозуміти помилки.

Якщо ви коли-небудь програмували на такій мові, як C / C ++, структури можна чудово використовувати як змінні. Просто передайте їх із посиланням, навколо, і нічого не може піти не так. Єдина проблема, яку я знаходжу, - це обмеження компілятора C #, і те, що в деяких випадках я не в змозі змусити дурну використовувати посилання на структуру, а не копію (наприклад, коли структура є частиною класу C # ).

Отже, змінні структури не є злими, C # зробив їх злими. Я весь час використовую змінні структури в C ++, і вони дуже зручні та інтуїтивно зрозумілі. На відміну від цього, C # змусив мене повністю відмовитися від структур як членів класів через те, як вони обробляють об'єкти. Їх зручність обійшлося нам.

Якщо ви будете дотримуватися того, для чого призначені структури (у C #, Visual Basic 6, Pascal / Delphi, C ++ тип структури (або класи), коли вони не використовуються в якості покажчиків), ви виявите, що структура не є більше, ніж складова змінна. . Це означає: ви будете трактувати їх як запакований набір змінних під загальним іменем (змінною запису, на яку ви посилаєтесь членів).

Я знаю, що це бентежить багато людей, які глибоко звикли до ООП, але це недостатньо підстав для того, щоб сказати, що такі речі притаманні злу, якщо їх правильно використовувати. Деякі структури є непорушними, як вони мають намір (це справа Пітона namedtuple), але це ще одна парадигма для розгляду.

Так: структури включають багато пам'яті, але це не буде точно більше пам'яті, виконуючи:

point.x = point.x + 1

у порівнянні з:

point = Point(point.x + 1, point.y)

Споживання пам'яті буде принаймні однаковим або навіть більшим у незмінному випадку (хоча цей випадок був би тимчасовим, для поточного стека залежно від мови).

Але, нарешті, структури - це структури , а не об’єкти. У POO головна властивість об’єкта - це їх ідентичність , яка в більшості випадків не більше його адреси пам'яті. Struct означає структуру даних (не належний об'єкт, і тому вони так і не мають ідентичності), і дані можна змінювати. В інших мовах запис (замість структури , як це стосується Паскаля) - це слово і має ту саму мету: просто змінна запис даних, призначена для читання з файлів, модифікація та скидання у файли (що є основним використання, і багатьма мовами ви навіть можете визначити вирівнювання даних у записі, хоча це не обов'язково стосується правильно названих об'єктів).

Хочете гарного прикладу? Структури використовуються для легкого читання файлів. У Python є ця бібліотека, оскільки, оскільки вона орієнтована на об'єкти і не підтримує структури, їй довелося реалізувати її іншим способом, який є дещо потворним. Мови, що реалізують структури, мають таку особливість ... вбудована. Спробуйте прочитати заголовок растрової карти з відповідною структурою на таких мовах, як Pascal або C. Це буде легко (якщо структура будується правильно і вирівнюється; в Pascal ви б не використовували доступ на основі запису, а функції для читання довільних бінарних даних). Отже, для файлів та прямого (локального) доступу до пам'яті структури краще, ніж об’єкти. Що стосується сьогодні, ми звикли до JSON та XML, і тому ми забуваємо про використання бінарних файлів (і як побічний ефект - використання структур). Але так: вони існують і мають мету.

Вони не злі. Просто використовуйте їх з правильною метою.

Якщо ви думаєте з точки зору молотків, ви захочете ставитися до гвинтів як до цвяхів, знайти шурупи важче занурити в стіну, і це буде вина саморізів, і вони будуть злими.

Уявіть, що у вас є масив з 1 000 000 струків. Кожна структура, що представляє власний капітал з такими речами, як bid_price, offer_price (можливо, десяткові дроби) тощо, це створюється C # / VB.

Уявіть, що масив створюється в блоці пам'яті, виділеному в некерованій купі, щоб якийсь інший нативний кодовий потік міг одночасно отримувати доступ до масиву (можливо, якийсь високопрофільний код, що займається математикою).

Уявіть, що код C # / VB прослуховує ринковий канал зміни цін, тому, можливо, коду доведеться отримати доступ до якогось елемента масиву (для забезпечення безпеки), а потім змінити деякі цінові поля.

Уявіть, що це робиться десятками, а то й сотнями тисяч разів на секунду.

Ну давайте зіткнутися з фактами; в цьому випадку ми дійсно хочемо, щоб ці структури були зміненими, вони повинні бути, тому що їм ділиться якийсь інший нативний код, тому створення копій не допоможе; це потрібно, тому що виготовлення копії приблизно 120-байтної структури за цими швидкостями є шаленістю, особливо коли оновлення насправді може вплинути на лише два байти.

Гюго

Коли щось можна мутувати, воно набуває почуття ідентичності.

struct Person {
    public string name; // mutable
    public Point position = new Point(0, 0); // mutable

    public Person(string name, Point position) { ... }
}

Person eric = new Person("Eric Lippert", new Point(4, 2));

Оскільки Personце мінливо, більш природно думати про зміну позиції Еріка, ніж клонування Еріка, переміщення клону та знищення оригіналу . Обидві операції могли б змінити вміст eric.position, але одна більш інтуїтивна, ніж інша. Крім того, інтуїтивніше передавати Еріку навколо (як орієнтир) методи його модифікації. Надання методу клону Еріка майже завжди буде дивовижним. Кожен, хто хоче мутувати, Personповинен пам’ятати, щоб попросити посилання на те, Personабо вони будуть робити неправильно.

Якщо ви зробите тип непорушним, проблема зникає; якщо я не можу модифікувати eric, для мене це не має ніякого значення, отримую я ericчи клонів eric. Більш загально, тип можна безпечно передати за значенням, якщо всі його спостережувані стану зберігаються у членів, які:

• непорушний
• еталонні типи
• безпечно пройти за значенням

Якщо ці умови дотримані, тип змінного значення веде себе як еталонний тип, оскільки неглибока копія все одно дозволить одержувачу змінювати вихідні дані.

Інтуїтивність незмінного Personзалежить від того, що ви намагаєтесь зробити. Якщо Personпросто представлений набір даних про людину, в цьому немає нічого неінтуїтивного; Personзмінні справді представляють абстрактні значення , а не об'єкти. (У такому випадку, ймовірно, буде доцільніше перейменувати його PersonData.) ЯкщоPerson насправді моделює сама людина, ідея постійно створювати та переміщувати клонів є дурною, навіть якщо ви уникали гніту думки, що ви змінюєте Оригінальний. У цьому випадку, мабуть, більш природно було б просто зробити Personтип посилання (тобто клас.)

Зрозуміло, як функціональне програмування навчило нас, є користь зробити все непорушним (ніхто не може таємно затримуватись посилання на нього ericта його мутувати), але оскільки це не ідіоматично в OOP, це все ще буде неінтуїтивним для всіх, хто працює з вашим код.

Це не має нічого спільного зі структурами (і не з C #), але в Java у вас можуть виникнути проблеми з об'єктами, що змінюються, якщо вони є, наприклад, ключами у хеш-карті. Якщо змінити їх, додавши їх до карти, і він змінить хеш-код , можуть трапитися злі речі.

Особисто, коли я дивлюсь на код, мені здається досить незграбним:

data.value.set (data.value.get () + 1);

а не просто

data.value ++; або data.value = data.value + 1;

Інкапсуляція даних корисна при проходженні класу навколо, і ви хочете переконатися, що значення змінюється контрольованим чином. Однак, коли у вас є загальнодоступні налаштування та отримання функцій, які роблять трохи більше, ніж задають значення тому, що коли-небудь передається, як це поліпшення порівняно з простою передачею публічної структури даних навколо?

Коли я створюю приватну структуру всередині класу, я створив цю структуру для організації набору змінних в одну групу. Я хочу мати змогу змінювати цю структуру в межах класу, не отримувати копії цієї структури та створювати нові екземпляри.

Для мене це перешкоджає правильному використанню структур для організації публічних змінних, якщо я хотів би контролювати доступ, я б використовував клас.

У прикладі містера Еріка Ліпперта є кілька питань. Надумано проілюструвати те, що структури копіюються, і як це може бути проблемою, якщо ви не обережні. Дивлячись на приклад, я бачу це як погану звичку програмування, а насправді не є проблемою ні для структури, ні для класу.

1. Структура повинна мати лише публічних членів і не повинна вимагати інкапсуляції. Якщо це так, то це дійсно має бути тип / клас. Вам дійсно не потрібно два конструкти, щоб сказати одне і те ж.

2. Якщо у вас клас закриває структуру, ви б викликали метод у класі мутувати структуру члена. Це те, що я б робив як гарну звичку програмування.

Правильна реалізація полягала б у наступному.

struct Mutable {
public int x;
}

class Test {
    private Mutable m = new Mutable();
    public int mutate()
    { 
        m.x = m.x + 1;
        return m.x;
    }
  }
  static void Main(string[] args) {
        Test t = new Test();
        System.Console.WriteLine(t.mutate());
        System.Console.WriteLine(t.mutate());
        System.Console.WriteLine(t.mutate());
    }

Схоже, це проблема із звичкою програмування, на відміну від проблеми із самою структурою. Структури повинні бути змінними, тобто ідея та наміри.

Результат змін вуаля веде себе як очікувалося:

1 2 3 Для продовження натисніть будь-яку клавішу. . .

У змінних даних є багато переваг і недоліків. Мільйон-доларовий недолік - це згладжування. Якщо одне і те ж значення використовується в декількох місцях, і одне з них його змінює, воно, схоже, магічно зміниться на інші місця, які його використовують. Це пов’язано з умовами перегонів, але не є ідентичним.

Перевага мільйона доларів - іноді модульність. Стан, що змінюється, дозволяє вам приховати зміни коду від коду, про який не потрібно знати про нього.

Мистецтво перекладача детально описує ці компроміси та наводить приклади.

Я не вірю, що вони злі, якщо їх правильно використовувати. Я б не вказував це у своєму виробничому коді, але я хотів би щось подібне до макетів тестування структурованих одиниць, де термін служби структури порівняно невеликий.

Використовуючи приклад Еріка, можливо, ви хочете створити другий екземпляр цього Еріка, але внести корективи, так як це характер вашого тесту (тобто дублювання, а потім модифікація). Не має значення, що відбувається з першим екземпляром Еріка, якщо ми просто використовуємо Eric2 для решти тестового сценарію, якщо тільки ви не плануєте використовувати його в якості тестового порівняння.

Це було б корисно для тестування чи зміни застарілого коду, який неглибоко визначає конкретний об'єкт (точку конструкцій), але, маючи незмінну структуру, це запобігає його дратівливому використанню.