Неизменяемость структур

Структуры должны представлять значения. Ценности не меняются. Число 12 вечно.

Однако учтите:

Foo foo = new Foo(); // a mutable struct
foo.Bar = 27;
Foo foo2 = foo;
foo2.Bar = 55;

Теперь foo.Bar и foo2.Bar разные, что часто бывает неожиданно. Особенно в таких сценариях, как свойства (к счастью, компилятор это обнаруживает). Но также коллекции и т. Д .; как вообще разумно их видоизменить?

С изменяемыми структурами потеря данных слишком проста.

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

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

РЕДАКТИРОВАТЬ: Я только что нашел электронное письмо, которое я написал некоторое время назад по этой теме. Он немного уточняет:

• С философской точки зрения это неправильно: структура должна представлять некую фундаментальную ценность. Они в основном неизменны. Вы не можете изменить число 5. Вы можете изменить значение переменной с 5 на 6, но вы не можете логически изменить само значение.

• Это практически проблема: возникает множество странных ситуаций. Особенно плохо, если его можно изменять через интерфейс. Затем вы можете начать изменять значения в коробках. Ик. Я видел много сообщений групп новостей, которые связаны с тем, что люди пытаются использовать изменяемые структуры и сталкиваются с проблемами. Я видел очень странный пример LINQ, который, например, терпел неудачу, потому что List<T>.Enumerator - это структура.

Я часто использую изменяемые структуры в своем (критичном к производительности) проекте - и у меня не возникает проблем, потому что я понимаю последствия семантики копирования. Насколько я могу судить, основная причина, по которой люди отстаивают неизменяемые структуры, заключается в том, чтобы люди, не понимающие последствия, не могли попасть в неприятности.

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

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

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

P.S. Чтобы избежать затрат на копирование изменяемых структур, они обычно хранятся и передаются в массивах.

Техническая причина в том, что изменяемые структуры кажутся способными делать то, чего они на самом деле не делают. Поскольку семантика времени разработки такая же, как у ссылочных типов, это сбивает разработчиков с толку. Этот код:

public void DoSomething(MySomething something)
{
    something.Property = 10;
}

Ведет себя по-разному в зависимости от того, является ли MySomething struct или class. Для меня это веская, но не самая веская причина. Если вы посмотрите на DDD Value Object, вы можете увидеть связь с тем, как следует обрабатывать структуры. Объект значения в DDD может быть лучше всего представлен как тип значения в .Net (и, следовательно, структура). Поскольку у него нет идентичности, он не может измениться.

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

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

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

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

Отличную статью о том, когда вы можете использовать изменяемые структуры, см. Производительность Рико Мариани. Тест по программированию на основе ценностей (или, более конкретно, ответы).

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

Семантика упрощается при использовании неизменяемых структур, и вы избегаете таких ловушек:

// a struct
struct Interval {
   int From { get; set; }
   int To { get; set; }
}

// create a list of structs
List<Interval> intervals = new List<Interval>();

// add a struct to the list
intervals.Add(new Interval());

// try to set the values of the struct
intervals[0].From = 10;
intervals[0].To = 20;

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

Изменить: изменен пример, чтобы использовать список вместо массива.

Когда вы копируете структуры вокруг, вы копируете их содержимое, поэтому, если вы измените скопированную версию, «оригинал» не будет обновлен.

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

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

Сохранение структур неизменными предотвращает это ...

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

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

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

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