可变结构体并不邪恶。

在高绩效环境下，它们是绝对必要的。例如，当缓存线和垃圾收集成为瓶颈时。

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

我可以看到c#的语法没有帮助区分值类型或引用类型的成员的访问，所以我完全赞成使用强制不变性的不可变结构，而不是可变结构。

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

例如:"struct是默认复制的值类型。如果你不想复制他们，你需要一份推荐信。 “首先尝试使用只读结构体”。

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

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

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

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

这对于测试或修改那些浅层定义特定对象(结构体的重点)的遗留代码非常有用，但是通过使用不可变的结构体，可以避免令人讨厌的使用。

李柏特先生举的例子有几个问题。它是为了说明结构是复制的，以及如果你不小心的话，这可能是一个问题。看看这个例子，我认为这是一个坏的编程习惯的结果，而不是结构或类的问题。

结构应该只有公共成员，不需要任何封装。如果是这样，那么它真的应该是一个类型/类。你真的不需要两个构念来表达同一件事。 如果有一个类包含一个结构，则可以调用该类中的一个方法来更改成员结构。我认为这是一个良好的编程习惯。

正确的实现如下所示。

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

看起来这是编程习惯的问题，而不是结构本身的问题。结构体应该是可变的，这是它的思想和意图。

更改的结果voila表现如预期:

1 2 3. 按任意键继续…

就我个人而言，当我看代码时，下面的代码看起来相当笨拙:

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

而不是简单地

数据.值++ ;或数据值 = 数据值 + 1 ;

数据封装在传递类时非常有用，并且您希望确保以受控的方式修改值。然而，当你拥有公共的set和get函数，它们所做的仅仅是将值设置为传递进来的值时，这比简单地传递公共数据结构有什么改进呢?

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

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

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

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

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

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