为什么可变结构是“邪恶的”？

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

因此，如果您更改副本，您只会更改该副本，而不是原始副本，也不会更改可能存在的任何其他副本。

如果您的结构是不可变的，那么所有由值传递产生的自动副本将是相同的。

如果你想改变它，你必须有意识地通过使用修改后的数据创建一个新的结构实例来做到这一点。 （不是副本）

---

从哪里开始;-p

Eric Lippert's blog 总是适合引用：

这是可变值类型邪恶的另一个原因。尝试始终使值类型不可变。

首先，您往往很容易丢失更改...例如，从列表中取出内容：

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;

不太重要的是，存在尺寸问题；可变对象倾向于具有多个属性；然而，如果你有一个包含两个 int、一个 string、一个 DateTime 和一个 bool 的结构，你可以很快消耗大量内存。使用一个类，多个调用者可以共享对同一个实例的引用（引用很小）。

---

我不会说邪恶，但可变性通常是程序员过度渴望提供最大功能的标志。实际上，这通常是不需要的，这反过来又使界面更小，更容易使用并且更难使用错误（=更健壮）。

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

Also, I claim that mutability is almost never actually needed，程序员只是认为它可能在未来。例如，更改日期根本没有意义。相反，根据旧日期创建一个新日期。这是一个廉价的操作，所以性能不是考虑因素。

---

可变结构并不邪恶。

它们在高性能环境中是绝对必要的。例如，当缓存行和/或垃圾收集成为瓶颈时。

我不会将在这些完全有效的用例中使用不可变结构称为“邪恶”。

我可以看到，C# 的语法无助于区分值类型或引用类型的成员的访问，所以我完全赞成不可变结构，它强制不可变，而不是可变结构。

然而，与其简单地将不可变结构标记为“邪恶”，我建议接受这种语言并提倡更有帮助和建设性的经验法则。

例如：“结构是值类型，默认情况下会复制。如果您不想复制它们，则需要参考”或“首先尝试使用只读结构”。

---

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

改变“this”的结构方法（与属性设置器不同）有点邪恶，只是因为.net 没有提供一种将它们与没有的方法区分开来的方法。不改变“this”的结构方法即使在只读结构上也应该是可调用的，不需要防御性复制。改变“this”的方法根本不应该在只读结构上调用。由于 .net 不想禁止不修改“this”的结构方法在只读结构上被调用，但又不想允许只读结构发生突变，所以它防御性地复制只读结构中的结构。只有上下文，可以说是两全其美。

然而，尽管在只读上下文中处理自变异方法存在问题，但可变结构通常提供远优于可变类类型的语义。考虑以下三个方法签名：

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()：否（明确意图） Method2()：是（明确意图） Method3()：是（不确定意图） 问题 2：Method1()：否 Method2()：否（除非不安全） Method3() ： 是的

Method1 无法修改 foo，并且永远不会获得引用。 Method2 获取对 foo 的短期引用，它可以使用它以任何顺序修改 foo 的字段任意次数，直到它返回，但它不能持久化该引用。在 Method2 返回之前，除非它使用了不安全的代码，否则任何和所有可能由其 'foo' 引用制作的副本都将消失。 Method3 与 Method2 不同，它获得对 foo 的混杂可共享的引用，并且不知道它可以用它做什么。它可能根本不会改变 foo，它可能会改变 foo 然后返回，或者它可能会将 foo 的引用提供给另一个线程，这可能会在未来的某个任意时间以某种任意方式对其进行变异。限制 Method3 对传递给它的可变类对象所做的唯一方法是将可变对象封装到只读包装器中，这既丑陋又麻烦。

结构数组提供了美妙的语义。给定 Rectangle 类型的 RectArray[500]，如何将元素 123 复制到元素 456，然后在一段时间后将元素 123 的宽度设置为 555，而不干扰元素 456，就很清楚了。“RectArray[432] = RectArray[321 ]; ...; RectArray[123].Width = 555;".知道 Rectangle 是一个结构体，它有一个名为 Width 的整数字段，这将告诉所有人都需要了解上述语句。

现在假设 RectClass 是一个与 Rectangle 具有相同字段的类，并且想要对 RectClass 类型的 RectClassArray[500] 执行相同的操作。也许该数组应该包含 500 个对可变 RectClass 对象的预初始化不可变引用。在这种情况下，正确的代码将类似于“RectClassArray[321].SetBounds(RectClassArray[456]); ...; RectClassArray[321].X = 555;”。也许该数组被假定包含不会改变的实例，所以正确的代码应该更像“RectClassArray[321] = RectClassArray[456]; ...; RectClassArray[321] = New RectClass(RectClassArray[321] ]); RectClassArray[321].X = 555;"要知道一个人应该做什么，就必须更多地了解 RectClass（例如，它是否支持复制构造函数、复制自方法等）以及数组的预期用途。远没有使用结构那么干净。

可以肯定的是，不幸的是，除了数组之外的任何容器类都没有很好的方法来提供结构数组的清晰语义。最好的办法是，如果想要用例如字符串对集合进行索引，可能会提供一个通用的“ActOnItem”方法，该方法将接受一个字符串作为索引、一个通用参数和一个将被传递的委托通过引用通用参数和集合项。这将允许与结构数组几乎相同的语义，但除非 vb.net 和 C# 人员能够提供良好的语法，否则即使性能合理（传递泛型参数将允许使用静态委托，并避免任何需要创建任何临时类实例）。

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

---

从程序员的角度来看，还有一些其他极端情况可能会导致不可预测的行为。

不可变值类型和只读字段

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

因此，只要您和团队的其他成员清楚地了解您在做什么，可变结构就不是邪恶的。但是当程序行为与预期不同时，有太多的极端情况，这可能导致难以产生和难以理解的细微错误。

---

值类型基本上代表了不可变的概念。 Fx，拥有一个整数、向量等数学值然后能够对其进行修改是没有意义的。这就像重新定义一个值的含义。与其更改值类型，不如分配另一个唯一值更有意义。考虑一下通过比较其属性的所有值来比较值类型的事实。关键是，如果属性相同，那么它就是该值的相同通用表示。

正如 Konrad 提到的那样，更改日期也没有意义，因为该值表示该唯一时间点，而不是具有任何状态或上下文相关性的时间对象的实例。

希望这对你有意义。可以肯定的是，它更多的是关于你试图用值类型捕捉的概念，而不是实际的细节。

---

如果您曾经使用 C/C++ 之类的语言进行过编程，那么结构体可以用作可变结构。只需将它们与 ref 一起传递，就不会出错。我发现的唯一问题是 C# 编译器的限制，在某些情况下，我无法强迫愚蠢的东西使用对结构的引用，而不是复制（比如当结构是 C# 类的一部分时）。

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

---

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

我知道这会让很多深深习惯于 OOP 的人感到困惑，但如果使用得当，这还不足以说明这些事情本质上是邪恶的。一些结构按照它们的意图是不可变的（这是 Python 的 namedtuple 的情况），但它是另一种需要考虑的范式。

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

point.x = point.x + 1

相比：

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

在不可变的情况下，内存消耗将至少相同，甚至更多（尽管对于当前堆栈而言，这种情况是暂时的，具体取决于语言）。

但是，最后，结构是结构，而不是对象。在 POO 中，对象的主要属性是它们的身份，大多数时候不超过其内存地址。 struct 代表数据结构（不是一个适当的对象，因此它们无论如何都没有身份），并且可以修改数据。在其他语言中，记录（而不是结构，就像 Pascal 的情况一样）是一个词并且具有相同的目的：只是一个数据记录变量，旨在从文件中读取、修改并转储到文件中（这是主要的使用，并且在许多语言中，您甚至可以在记录中定义数据对齐，而正确调用的对象不一定是这种情况）。

想要一个好例子吗？结构用于轻松读取文件。 Python 之所以有 this library，是因为它是面向对象的并且不支持结构，所以它必须以另一种方式实现它，这有点难看。实现结构的语言具有该功能......内置。尝试用 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 的位置比考虑克隆 Eric、移动克隆体并破坏原始体更为自然。这两种操作都可以成功地改变 eric.position 的内容，但一种比另一种更直观。同样，传递 Eric（作为参考）以获取修改他的方法更直观。给一个方法一个 Eric 的克隆几乎总是令人惊讶。任何想要改变 Person 的人都必须记得请求对 Person 的引用，否则他们会做错事。

如果你使类型不可变，问题就消失了；如果我无法修改 eric，我收到 eric 或 eric 的克隆对我没有任何影响。更一般地说，如果一个类型的所有可观察状态都保存在以下成员中，则该类型可以安全地按值传递：

不可变

引用类型

按值安全传递

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

不可变 Person 的直观性取决于您尝试执行的操作。如果 Person 只代表一个人的数据集，那么它并没有什么不直观的地方； Person 变量真正代表抽象值，而不是对象。 （在这种情况下，将其重命名为 PersonData 可能更合适。）如果 Person 实际上是在为一个人本身建模，那么即使您避免了陷阱，不断创建和移动克隆的想法也是愚蠢的认为你正在修改原件。在这种情况下，简单地将 Person 设为引用类型（即类）可能更自然。

诚然，正如函数式编程告诉我们的那样，使 everything 不可变是有好处的（没有人可以偷偷地持有对 eric 的引用并改变他），但由于这在 OOP 中不是惯用的，所以它仍然是对于其他使用您的代码的人来说，这将是不直观的。

---

它与结构无关（也与 C# 无关），但在 Java 中，当可变对象是哈希映射中的键时，您可能会遇到可变对象的问题。如果您在将它们添加到地图后更改它们并更改其 hash code，则可能会发生邪恶的事情。

---

可变数据有很多优点和缺点。百万美元的劣势是混叠。如果在多个地方使用相同的值，并且其中一个更改了它，那么它似乎已经神奇地更改为正在使用它的其他地方。这与竞态条件有关，但并不完全相同。

有时，百万美元的优势是模块化。可变状态可以让您从不需要知道的代码中隐藏变化的信息。

The Art of the Interpreter 详细介绍了这些权衡，并给出了一些示例。

---

就我个人而言，当我查看代码时，以下代码对我来说看起来很笨拙：

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

而不是简单的

数据.值++；或 data.value = data.value + 1 ；

当传递一个类并且您希望确保以受控方式修改值时，数据封装很有用。然而，当你有公共的 set 和 get 函数只是将值设置为传入的值时，与简单地传递公共数据结构相比，这有什么改进？

当我在类中创建私有结构时，我创建了该结构以将一组变量组织到一个组中。我希望能够在类范围内修改该结构，而不是获取该结构的副本并创建新实例。

对我来说，这阻止了有效使用用于组织公共变量的结构，如果我想要访问控制，我会使用一个类。

---

Eric Lippert 先生的例子有几个问题。它旨在说明复制结构的要点以及如果您不小心，这可能会成为问题。看一下这个例子，我认为这是一个不好的编程习惯的结果，而不是结构或类的问题。

结构应该只有公共成员，不需要任何封装。如果是这样，那么它真的应该是一个类型/类。你真的不需要两个结构来说同样的事情。如果你有一个包含结构的类，你会调用类中的一个方法来改变成员结构。这就是我会做的一个好的编程习惯。

正确的实现如下。

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 按任意键继续。 . .

---

如果使用得当，我不相信它们是邪恶的。我不会将它放在我的生产代码中，但我会使用结构化单元测试模拟之类的东西，其中结构的生命周期相对较小。

使用 Eric 示例，也许您想创建该 Eric 的第二个实例，但要进行调整，因为这是您的测试的本质（即复制，然后修改）。如果我们只是将 Eric2 用于测试脚本的其余部分，那么 Eric 的第一个实例会发生什么并不重要，除非您打算将他用作测试比较。

这对于测试或修改浅定义特定对象（结构点）的遗留代码非常有用，但是通过具有不可变结构，这可以防止它的使用令人讨厌。

---