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

Question

在关于 SO 的讨论之后，我已经多次读到可变结构是“邪恶的”的评论（就像这个问题）。

C# 中的可变性和结构的实际问题是什么？

Answer 1

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

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

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

如果您想更改它，您必须有意识地使用修改后的数据创建结构的新实例。 （不是副本）

Answer 2

从哪里开始 ;-p

Eric Lippert 的博客总是适合引用：

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

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

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 的结构，您可以很快就会消耗大量内存。 对于一个类，多个调用者可以共享对同一实例的引用（引用很小）。

Answer 3

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

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

此外，我声称实际上几乎从来不需要可变性，程序员只是认为它可能在未来。 例如，更改日期根本没有意义。 相反，根据旧日期创建一个新日期。 这是一个廉价的操作，因此性能不是考虑因素。

Answer 4

可变结构并不是邪恶的。

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

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

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

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

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

Answer 5

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

改变“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);

对于每个方法，回答以下问题：

1. 假设该方法不使用任何“不安全”代码，它是否会修改 foo？
2. 如果在调用该方法之前不存在对“foo”的外部引用，那么在调用该方法之后是否可能存在外部引用？

_答案：

问题1：
Method1()：无（明确意图）
Method2()：是（明确意图）
Method3()：是（不确定意图）
问题2：
Method1()：否
Method2()：无（除非不安全）
Method3()：是

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

结构数组提供了美妙的语义。 给定 Rectangle 类型的 RectArray[500]，很明显如何将元素 123 复制到元素 456，然后一段时间后将元素 123 的宽度设置为 555，而不干扰元素 456。“ RectArray[432] = RectArray[321 ]; 矩形数组[123].宽度= 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 ]); 矩形类数组[321].X = 555;" 要知道应该做什么，就必须了解有关 RectClass 的更多信息（例如，它是否支持复制构造函数、复制源方法等）以及数组的预期用途。 远没有使用结构那么干净。

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

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

Answer 6

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

不可变值类型和只读字段

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

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

Answer 7

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

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

希望这对您有意义。 当然，它更多的是关于您尝试用值类型捕获的概念，而不是实际细节。

Answer 8

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

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

Answer 9

想象一下您有一个包含 1,000,000 个结构的数组。 每个结构代表一个权益，包含 bid_price、offer_price（可能是小数）等内容，这是由 C#/VB 创建的。

想象一下，该数组是在非托管堆中分配的内存块中创建的，以便其他一些本机代码线程能够同时访问该数组（可能是一些执行数学运算的高性能代码）。

想象一下 C#/VB 代码正在侦听价格变化的市场反馈，该代码可能必须访问数组的某些元素（无论哪种证券），然后修改某些价格字段。

想象一下每秒执行数万甚至数十万次。

好吧，让我们面对事实，在这种情况下，我们确实希望这些结构是可变的，它们需要是可变的，因为它们正在被其他一些本机代码共享，所以创建副本不会有帮助； 它们需要如此，因为以这样的速率复制一些 120 字节结构的副本是疯狂的，特别是当更新实际上可能只影响一两个字节时。

雨果

Answer 10

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

我知道这会让很多习惯 OOP 的人感到困惑，但是如果使用得当，这并不足以说明这些东西本质上是邪恶的。 有些结构按照其预期是不可变的（Python 的 namedtuple 就是这种情况），但这是需要考虑的另一种范例。

是的：结构体涉及大量内存，但通过执行以下操作不会精确地获得更多内存：

point.x = point.x + 1

与： 相比：

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

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

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

想要一个好的例子吗？ 结构体用于轻松读取文件。 Python 有这个库，因为它是面向对象的并且不支持结构，所以它必须以另一种方式实现它，这有点难看。 实现结构的语言具有该功能......内置。 尝试用 Pascal 或 C 等语言读取具有适当结构的位图标头。这会很容易（如果结构正确构建和对齐；在 Pascal 中，您不会使用基于记录的访问，而是使用读取任意二进制数据的函数）。 因此，对于文件和直接（本地）内存访问，结构比对象更好。 就今天而言，我们已经习惯了 JSON 和 XML，因此我们忘记了二进制文件的使用（以及副作用，忘记了结构的使用）。 但是，是的：它们存在，并且有目的。

他们并不邪恶。 只需将它们用于正确的目的即可。

如果你用锤子来思考，你就会想把螺丝钉当作钉子，发现螺丝钉更难扎进墙里，那就是螺丝钉的错，是螺丝钉的祸害。

Answer 11

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

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 设为引用类型（即类）可能会更自然。

当然，正如函数式编程告诉我们的那样，将所有东西都设为是有好处的。 /em> 不可变（没有人可以秘密保留对 eric 的引用并改变他），但由于这在 OOP 中不是惯用的，所以对于其他使用你的代码的人来说仍然是不直观的。

Answer 12

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

Answer 13

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

有时，数百万美元的优势在于模块化。 可变状态可以让您对不需要了解变化的信息隐藏代码。

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

Answer 14

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

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

而不是简单的

data.value++ ； 或 data.value = data.value + 1 ；

当传递类并且您希望确保以受控方式修改值时，数据封装非常有用。 然而，当您拥有公共 set 和 get 函数时，它们的作用只不过是将值设置为传入的值，那么与简单地传递公共数据结构相比，这有何改进呢？

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

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

Answer 15

埃里克·利珀特先生的例子有几个问题。 它旨在说明复制结构的这一点以及如果您不小心的话这可能会出现问题。 看看这个例子，我认为这是不良编程习惯的结果，而不是结构或类的真正问题。

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

Answer 16

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

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

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