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

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

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

Если вы когда-либо программировали на таком языке, как C / C ++, структуры можно использовать как изменяемые. Просто передайте их с помощью ref, around, и ничего не может пойти не так. Единственная проблема, которую я обнаружил, - это ограничения компилятора C # и то, что в некоторых случаях я не могу заставить эту глупость использовать ссылку на структуру вместо копии (например, когда структура является частью класса C # ).

Итак, изменяемые структуры - это не зло, C # сделал их злыми. Я постоянно использую изменяемые структуры в C ++, они очень удобны и интуитивно понятны. Напротив, C # заставил меня полностью отказаться от структур как членов классов из-за того, как они обрабатывают объекты. Их удобство стоило нам нашего.

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

Я знаю, что это сбило бы с толку многих людей, глубоко привыкших к ООП, но этого недостаточно, чтобы говорить, что такие вещи изначально злы, если они используются правильно. Некоторые структуры неизменяемы по своему назначению (это случай namedtuple в Python), но это еще одна парадигма, которую следует рассмотреть.

Да: структуры требуют много памяти, но это не будет точно больше памяти, если:

point.x = point.x + 1

по сравнению с:

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

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

Но, наконец, структуры - это структуры, а не объекты. В POO основным свойством объекта является его идентичность, которая в большинстве случаев не превышает его адрес в памяти. Struct обозначает структуру данных (не правильный объект, поэтому у них все равно нет идентичности), и данные могут быть изменены. В других языках запись (вместо 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 и изменять его), но, поскольку это не идиоматично в ООП, оно все равно будет быть не интуитивно понятным для всех, кто работает с вашим кодом.

Это не имеет ничего общего со структурами (и не с C # тоже), но в Java у вас могут возникнуть проблемы с изменяемыми объектами, когда они, например, ключи в хэш-карте. Если вы измените их после добавления на карту, и это изменит его хэш-код, могут случиться злые дела.

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

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

Искусство переводчика подробно рассматривает эти компромиссы и приводит некоторые примеры.

Лично, когда я смотрю на код, мне кажется, что следующее выглядит довольно неуклюже:

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

а не просто

data.value ++; или data.value = data.value + 1;

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

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

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

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

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 Нажмите любую кнопку, чтобы продолжить. . .

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

Используя пример Эрика, возможно, вы захотите создать второй экземпляр этого Эрика, но внесите изменения, так как это характер вашего теста (т. Е. Дублирование, а затем изменение). Не имеет значения, что происходит с первым экземпляром Эрика, если мы просто используем Эрика2 для оставшейся части тестового сценария, если только вы не планируете использовать его в качестве тестового сравнения.

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