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

不可变值类型和只读字段

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

可变值类型和数组

假设我们有一个可变结构的数组，我们为该数组的第一个元素调用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);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而不是简单地

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

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

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

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