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

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

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

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

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

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

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

如果你曾经用C/ c++这样的语言编程，结构体可以作为可变的。只要把球传给裁判，没有什么会出错的。我发现的唯一问题是c#编译器的限制，在某些情况下，我无法强迫这个愚蠢的东西使用对结构的引用，而不是Copy(比如当结构是c#类的一部分时)。

所以，可变结构体不是邪恶的，是c#把它们变成了邪恶的。我一直在c++中使用可变结构体，它们非常方便和直观。相比之下，c#让我完全放弃了作为类成员的结构体，因为它们处理对象的方式。他们的便利让我们付出了代价。

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

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中不是惯用的，因此对于使用您的代码的其他人来说仍然是不直观的。

我不会说可变性是邪恶的，但可变性通常是程序员急于提供最大功能的标志。在现实中，这通常是不需要的，反过来，使界面更小，更容易使用，更难使用错误(=更健壮)。

其中一个例子就是竞态条件中的读/写和写/写冲突。这些在不可变结构中根本不可能发生，因为写操作不是有效的操作。

另外，我认为可变性几乎从来都不是真正需要的，程序员只是认为它在未来可能会出现。例如，改变日期是没有意义的。相反，在旧日期的基础上创建一个新的日期。这是一个廉价的操作，所以性能不是一个考虑因素。

具有公共可变字段或属性的结构并不邪恶。

Struct methods (as distinct from property setters) which mutate "this" are somewhat evil, only because .net doesn't provide a means of distinguishing them from methods which do not. Struct methods that do not mutate "this" should be invokable even on read-only structs without any need for defensive copying. Methods which do mutate "this" should not be invokable at all on read-only structs. Since .net doesn't want to forbid struct methods that don't modify "this" from being invoked on read-only structs, but doesn't want to allow read-only structs to be mutated, it defensively copies structs in read-only contexts, arguably getting the worst of both worlds.

尽管在只读上下文中处理自突变方法存在问题，但是，可变结构通常提供的语义要比可变类类型优越得多。考虑以下三个方法签名:

struct PointyStruct {public int x,y,z;};
class PointyClass {public int x,y,z;};

void Method1(PointyStruct foo);
void Method2(ref PointyStruct foo);
void Method3(PointyClass foo);

对于每种方法，请回答以下问题:

假设该方法没有使用任何“不安全”代码，它会修改foo吗? 如果在调用方法之前没有对'foo'的外部引用，那么在调用方法之后是否可以存在外部引用?

答案:

问题1: Method1(): no(意图明确) Method2(): yes(明确的意图) Method3(): yes(不确定意图) 问题2: Method1():没有 Method2(): no(除非不安全) Method3():是的

Method1 can't modify foo, and never gets a reference. Method2 gets a short-lived reference to foo, which it can use modify the fields of foo any number of times, in any order, until it returns, but it can't persist that reference. Before Method2 returns, unless it uses unsafe code, any and all copies that might have been made of its 'foo' reference will have disappeared. Method3, unlike Method2, gets a promiscuously-sharable reference to foo, and there's no telling what it might do with it. It might not change foo at all, it might change foo and then return, or it might give a reference to foo to another thread which might mutate it in some arbitrary way at some arbitrary future time. The only way to limit what Method3 might do to a mutable class object passed into it would be to encapsulate the mutable object into a read-only wrapper, which is ugly and cumbersome.

结构数组提供了美妙的语义。给定矩形类型的RectArray[500]，如何将元素123复制到元素456，然后在不影响元素456的情况下，将元素123的宽度设置为555是显而易见的。"RectArray[432] = RectArray[321];…;RectArray[123]。宽度= 555;"。知道Rectangle是一个具有名为Width的整数字段的结构体，就可以知道关于上述语句的所有信息。

Now suppose RectClass was a class with the same fields as Rectangle and one wanted to do the same operations on a RectClassArray[500] of type RectClass. Perhaps the array is supposed to hold 500 pre-initialized immutable references to mutable RectClass objects. in that case, the proper code would be something like "RectClassArray[321].SetBounds(RectClassArray[456]); ...; RectClassArray[321].X = 555;". Perhaps the array is assumed to hold instances that aren't going to change, so the proper code would be more like "RectClassArray[321] = RectClassArray[456]; ...; RectClassArray[321] = New RectClass(RectClassArray[321]); RectClassArray[321].X = 555;" To know what one is supposed to do, one would have to know a lot more both about RectClass (e.g. does it support a copy constructor, a copy-from method, etc.) and the intended usage of the array. Nowhere near as clean as using a struct.

To be sure, there is unfortunately no nice way for any container class other than an array to offer the clean semantics of a struct array. The best one could do, if one wanted a collection to be indexed with e.g. a string, would probably be to offer a generic "ActOnItem" method which would accept a string for the index, a generic parameter, and a delegate which would be passed by reference both the generic parameter and the collection item. That would allow nearly the same semantics as struct arrays, but unless the vb.net and C# people can be pursuaded to offer a nice syntax, the code is going to be clunky-looking even if it is reasonably performance (passing a generic parameter would allow for use of a static delegate and would avoid any need to create any temporary class instances).

就我个人而言，我对Eric Lippert等人对可变值类型的憎恨感到恼火。它们提供了比到处使用的混杂引用类型清晰得多的语义。尽管.net对值类型的支持有一些限制，但在许多情况下，可变值类型比任何其他类型的实体都更适合。