可变数据有许多优点和缺点。最大的缺点就是别名。如果相同的值在多个地方使用，其中一个地方更改了它，那么它将神奇地更改到正在使用它的其他地方。这与竞态条件有关，但并不完全相同。

有时候，价值百万美元的优势是模块化。可变状态允许您向代码隐藏更改的信息，而代码不需要知道这些信息。

《解释器的艺术》详细讨论了这些权衡，并给出了一些例子。

如果你坚持结构体的用途(在c#、Visual Basic 6、Pascal/Delphi、c++结构类型(或类)中，当它们不用作指针时)，你会发现结构体只不过是一个复合变量。这意味着:您将把它们视为一个通用名称(您引用成员的记录变量)下的一组变量。

我知道这会让很多习惯于面向对象编程的人感到困惑，但如果使用得当，这并不是说这些东西本质上是邪恶的理由。有些结构按照它们的意图是不可变的(Python的namedtuple就是这种情况)，但这是另一种需要考虑的范例。

是的:结构体涉及大量内存，但它不会精确地通过执行以下操作来增加内存:

point.x = point.x + 1

相比:

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

在不可变的情况下，内存消耗至少是相同的，甚至更多(尽管这种情况对于当前堆栈来说是临时的，这取决于语言)。

But, finally, structures are structures, not objects. In POO, the main property of an object is their identity, which most of the times is not more than its memory address. Struct stands for data structure (not a proper object, and so they don't have identity anyhow), and data can be modified. In other languages, record (instead of struct, as is the case for Pascal) is the word and holds the same purpose: just a data record variable, intended to be read from files, modified, and dumped into files (that is the main use and, in many languages, you can even define data alignment in the record, while that's not necessarily the case for properly called Objects).

Want a good example? Structs are used to read files easily. Python has this library because, since it is object-oriented and has no support for structs, it had to implement it in another way, which is somewhat ugly. Languages implementing structs have that feature... built-in. Try reading a bitmap header with an appropriate struct in languages like Pascal or C. It will be easy (if the struct is properly built and aligned; in Pascal you would not use a record-based access but functions to read arbitrary binary data). So, for files and direct (local) memory access, structs are better than objects. As for today, we're used to JSON and XML, and so we forget the use of binary files (and as a side effect, the use of structs). But yes: they exist, and have a purpose.

他们并不邪恶。只要把它们用在正确的地方。

如果你从锤子的角度思考，你会想把螺丝当作钉子，发现螺丝更难扎进墙里，这将是螺丝的错，它们将是邪恶的。

Value types basically represents immutable concepts. Fx, it makes no sense to have a mathematical value such as an integer, vector etc. and then be able to modify it. That would be like redefining the meaning of a value. Instead of changing a value type, it makes more sense to assign another unique value. Think about the fact that value types are compared by comparing all the values of its properties. The point is that if the properties are the same then it is the same universal representation of that value.

正如Konrad所提到的，更改日期也没有意义，因为值代表的是唯一的时间点，而不是具有任何状态或上下文依赖关系的时间对象的实例。

希望这能让你明白。可以肯定的是，它更多的是关于您试图用值类型捕获的概念，而不是实际的细节。

可变数据有许多优点和缺点。最大的缺点就是别名。如果相同的值在多个地方使用，其中一个地方更改了它，那么它将神奇地更改到正在使用它的其他地方。这与竞态条件有关，但并不完全相同。

有时候，价值百万美元的优势是模块化。可变状态允许您向代码隐藏更改的信息，而代码不需要知道这些信息。

《解释器的艺术》详细讨论了这些权衡，并给出了一些例子。

结构是值类型，这意味着它们在传递时被复制。

所以如果你改变了一份副本，你只是改变了那份副本，而不是原件，也不是周围可能存在的其他副本。

如果你的struct是不可变的，那么所有通过值传递的自动副本都是相同的。

如果你想要改变它，你必须有意识地用修改过的数据创建一个结构的新实例。(非副本)

当某种东西可以变异时，它就获得了一种认同感。

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));

Because Person is mutable, it's more natural to think about changing Eric's position than cloning Eric, moving the clone, and destroying the original. Both operations would succeed in changing the contents of eric.position, but one is more intuitive than the other. Likewise, it's more intuitive to pass Eric around (as a reference) for methods to modify him. Giving a method a clone of Eric is almost always going to be surprising. Anyone wanting to mutate Person must remember to ask for a reference to Person or they'll be doing the wrong thing.

如果你让类型是不可变的，这个问题就消失了;如果我不能修改eric，无论我收到eric还是eric的克隆对我来说都没有区别。更一般地说，如果类型的所有可观察状态都保存在以下成员中，则按值传递是安全的:

不可变的 引用类型 安全通过价值

如果满足这些条件，那么可变值类型的行为就像引用类型一样，因为浅拷贝仍然允许接收方修改原始数据。

The intuitiveness of an immutable Person depends on what you're trying to do though. If Person just represents a set of data about a person, there's nothing unintuitive about it; Person variables truly represent abstract values, not objects. (In that case, it'd probably be more appropriate to rename it to PersonData.) If Person is actually modeling a person itself, the idea of constantly creating and moving clones is silly even if you've avoided the pitfall of thinking you're modifying the original. In that case it'd probably be more natural to simply make Person a reference type (that is, a class.)

诚然，函数式编程已经告诉我们，使所有东西都不可变是有好处的(没有人可以秘密地保留对eric的引用并改变他)，但由于这在OOP中不是惯用的，因此对于使用您的代码的其他人来说仍然是不直观的。