例如："structs are value types, which are copied by default. you need a reference if you don't want to copy them"或"try to work with readonly structs first" .
270
Structs with public mutable fields or properties are not evil.
`` `// Simple mutable structure. // Method IncrementI mutates current state. struct Mutable { public Mutable(int i) : this()
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[] 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 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 成为引用类型（即类）可能更自然 .
当然，正如函数式编程告诉我们的那样，使一切都变得不可变（没有人可以秘密地保留对 eric 的引用并且让他变异），但是因为那个's not idiomatic in OOP it'对于使用你的代码的任何其他人来说仍然是不直观的 .
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());
}
16 回答
结构是值类型，这意味着它们在传递时被复制 .
因此，如果您更改副本，则只更改该副本，而不是原始副本，而不是可能存在的任何其他副本 .
如果您的结构是不可变的，则通过值传递的所有自动副本将是相同的 .
如果要更改它，则必须通过使用修改后的数据创建结构的新实例来有意识地执行此操作 . （不是副本）
从哪里开始;-p
Eric Lippert's blog总是对报价有好处：
首先，您很容易丢失更改...例如，从列表中获取内容：
那改变了什么？什么都没有用......
与属性相同：
强迫你这样做：
不太重要的是，存在尺寸问题;可变对象 tend 具有多个属性;但是如果你有一个带有两个
int的结构，一个string，一个DateTime和一个bool，你可以很快地烧掉大量的内存 . 对于类，多个调用者可以共享对同一实例的引用（引用很小） .我不会说邪恶，但可变性通常是程序员过度使用以提供最大功能的标志 . 实际上，这通常是不需要的，反过来又会使界面更小，更易于使用并且更难以使用错误（更强大） .
其中一个例子是竞争条件下的读/写和写/写冲突 . 这些不可能在不可变结构中出现，因为写入不是有效操作 .
Also, I claim that mutability is almost never actually needed，程序员只是认为它可能在未来 . 例如，更改日期根本没有意义 . 而是根据旧日期创建一个新日期 . 这是一种廉价的操作，因此性能不是考虑因素 .
可变结构不是邪恶的 .
它们在高性能环境中是绝对必要的 . 例如，当缓存行和/或垃圾收集成为瓶颈时 .
我不会在这些完全有效的用例“邪恶”中使用不可变结构 .
我可以看到，C＃的语法不利于区分值类型或引用类型的成员的接入点，所以我所有喜欢一成不变的结构，即强制执行不变性，在可变的结构 .
然而，我并不是简单地将不可变结构标记为“邪恶”，而是建议采用该语言并倡导更有帮助和建设性的经验法则 .
例如："structs are value types, which are copied by default. you need a reference if you don't want to copy them"或"try to work with readonly structs first" .
Structs with public mutable fields or properties are not evil.
改变“this”的结构方法（与属性设置者不同）有点恶，只是因为.net没有提供区分它们的方法 . 不改变“this”的struct方法即使在只读结构上也应该是可调用的，而不需要防御性复制 . 修改“this”的方法在只读结构上根本不应该是可调用的 . 由于.NET不希望禁止结构方法不修改“这个”从只读结构被调用，但不希望允许只读结构发生突变，但防守副本只读结构唯一的背景，可以说是两个世界中最糟糕的 .
尽管在只读上下文中处理自变异方法存在问题，但是可变结构通常提供远远优于可变类类型的语义 . 考虑以下三种方法签名：
对于每种方法，请回答以下问题：
假设该方法不使用任何"unsafe"代码，它可能会修改foo吗？
如果在调用方法之前没有对'foo'的外部引用，那么之后是否存在外部引用？
回答：
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]; ...; 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（例如它是否支持复制构造函数，复制方法等）以及数组的预期用法 . 远远不如使用结构那么干净 .
可以肯定的是，遗憾的是，除了数组之外的任何容器类都没有很好的方法来提供struct数组的干净语义 . 最好的人可以做，如果一个人想要一个集合被索引，例如一个字符串，可能是提供一个通用的“ActOnItem”方法，它接受索引的字符串，泛型参数和委托，它将通过引用泛型参数和集合项来传递 . 这将允许几乎与struct数组相同的语义，但除非可以追求vb.net和C＃人员提供一个很好的语法，即使它是合理的性能，代码也会变得笨拙（传递一个通用参数会允许使用静态委托，并避免任何需要创建任何临时类实例） .
就个人而言，我对仇恨Eric Lippert等人感到不满 . 关于可变值类型的喷射 . 它们提供比在各处使用的混杂引用类型更清晰的语义 . 尽管.net支持值类型存在一些限制，但在许多情况下，可变值类型比任何其他类型的实体更适合 .
值类型基本上表示不可变的概念 . Fx，有一个数学值，如整数，向量等没有意义，然后能够修改它 . 这就像重新定义 Value 的含义一样 . 而不是更改值类型，分配另一个唯一值更有意义 . 考虑通过比较其属性的所有值来比较值类型的事实 . 关键是如果属性相同，那么它就是该值的通用表示 .
正如Konrad所提到的那样，更改日期也没有意义，因为值表示唯一的时间点，而不是具有任何状态或上下文依赖性的时间对象的实例 .
希望这对你有意义 . 更确切地说，它更多地是关于您尝试使用值类型而非实际细节捕获的概念 .
从程序员的角度来看，还有另外几个可能导致不可预测行为的案例 . 这里有几个 .
``
`// Simple mutable structure.
// Method IncrementI mutates current state.
struct Mutable
{
public Mutable(int i) : this()
}
// 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);
}`
``
假设有一个Mutable结构的数组，我们为该数组的第一个元素调用IncrementI方法 . 你对这次电话的期待是什么？它应该更改数组的值还是仅更改副本？
所以，只要你和团队的其他成员清楚地了解你在做什么，可变结构就不是邪恶的 . 但是，当程序行为与预期行为不同时，存在太多极端情况，这可能导致难以产生和难以理解的错误 .
如果你曾经用C / C这样的语言进行编程，那么结构体可以用作可变的 . 只需用ref传递它们，周围就没有什么可以出错的 . 我发现的唯一问题是C＃编译器的限制，在某些情况下，我无法强制使用对结构的引用而不是复制（就像结构是C＃类的一部分时一样） ） .
因此，可变结构不是邪恶的，C＃使它们变得邪恶 . 我一直在C中使用可变结构，它们非常方便直观 . 相比之下，C＃让我完全放弃了作为类成员的结构，因为它们处理对象的方式 . 他们的便利花了我们的钱 .
想象一下，你有一个1,000,000个结构阵列 . 每struct表示与bid_price，offer_price（可能是小数）等东西的股权，这是由C＃/ VB创建的 .
想象一下，数组是在非托管堆中分配的内存块中创建的，这样一些其他本机代码线程就能够同时访问该数组（可能是一些高性能代码进行数学运算） .
想象一下，C＃/ VB代码正在收听价格变化的市场反馈，该代码可能必须访问数组的某些元素（无论哪种安全性），然后修改一些价格字段 .
想象一下，这每秒要做几十甚至几十万次 .
好吧，让我们面对事实，在这种情况下，我们确实希望这些结构是可变的，它们需要是因为它们被其他一些本机代码共享所以创建副本不会有帮助;它们需要是因为以这些速率制作一些120字节结构的副本是疯狂的，特别是当更新实际上只影响一两个字节时 .
雨果
如果您坚持使用什么结构（在C＃，Visual Basic 6，Pascal / Delphi，C结构类型（或类）中它们不用作指针时），您会发现结构不超过复合变量 . 这意味着：您将在一个通用名称（引用成员的记录变量）下将它们视为一组压缩变量 .
我知道这会让很多人习惯于OOP而感到困惑，但是，这是另一个需要考虑的范例 .
是的：结构涉及大量内存，但通过执行以下操作将不会更多内存：
相比：
在不可知的情况下，内存消耗至少相同，甚至更多（尽管这种情况对于当前堆栈是暂时的，取决于语言） .
但是，最后，结构是结构，而不是对象 . 在POO中，对象的主要属性是它们的身份，大多数时间不超过其内存地址 . Struct代表数据结构（不是适当的对象，因此无论如何它们都没有标识），并且可以修改数据 . 在其他语言中，记录（而不是结构，如Pascal的情况）是单词并且具有相同的目的：只是一个数据记录变量，旨在从文件中读取，修改并转储到文件中（这是主要的）使用和，在许多语言中，您甚至可以在记录中定义数据对齐，而对于正确调用的对象则不一定如此 .
想要一个好榜样吗？结构用于轻松读取文件 . Python有this library因为它是面向对象的并且不支持结构，所以它必须以另一种方式实现它，这有点难看 . 实现结构的语言具有内置的功能 . 尝试使用Pascal或C等语言中的适当结构读取位图标头 . 这将很容易（如果结构正确构建并对齐;在Pascal中，您不会使用基于记录的访问，而是用于读取任意二进制数据） . 因此，对于文件和直接（本地）内存访问，结构比对象更好 . 至于今天，我们已经习惯了JSON和XML，所以我们忘记了二进制文件的使用（并且作为副作用，结构的使用） . 但是是的：它们存在，并且有目的 .
他们不是邪恶的 . 只是将它们用于正确的目的 .
如果你想到锤子，你会想要把螺丝当作钉子，找到螺丝更难以插入墙壁，这将是螺丝的错，它们将是邪恶的 .
当某些东西可以变异时，它会获得一种认同感 .
因为
Person是可变的，所以考虑改变Eric的位置比克隆Eric，移动克隆和破坏原始内容更自然 . 这两个操作都会成功更改eric.position的内容，但是一个操作比另一个更直观 . 同样，通过Eric（作为参考）传递修改他的方法更为直观 . 给一个方法克隆Eric几乎总是令人惊讶 . 任何想要改变Person的人都必须记得要求提及Person，否则他们会做错事 .如果你使类型不可变，问题就会消失;如果我不能修改
eric，那么我收到eric或eric的克隆是没有区别的 . 更一般地说，如果一个类型的所有可观察状态都保存在以下成员中，则可以安全地传递值：不可变
引用类型
安全传递值
如果满足这些条件，则可变值类型的行为类似于引用类型，因为浅副本仍将允许接收器修改原始数据 .
不可变的
Person的直观性取决于你想要做的事情 . 如果Person只是代表一组关于一个人的数据，那么就没有什么不直观的了;Person变量真正代表抽象值，而不是对象 . （在这种情况下，将它重命名为PersonData可能更合适 . ）如果Person实际上正在为一个人自己建模，那么即使你正在修改原始内容，不断创建和移动克隆也是愚蠢的 . 在这种情况下，简单地使Person成为引用类型（即类）可能更自然 .当然，正如函数式编程告诉我们的那样，使一切都变得不可变（没有人可以秘密地保留对
eric的引用并且让他变异），但是因为那个's not idiomatic in OOP it'对于使用你的代码的任何其他人来说仍然是不直观的 .它与结构没有任何关系（也没有与C＃有关）但是在Java中你可能会遇到可变对象的问题 . 哈希映射中的键 . 如果在将它们添加到 Map 后更改它们并且它会更改它hash code，则可能会发生恶意事件 .
就个人而言，当我查看代码时，以下内容对我来说非常笨重：
data.value.set（data.value.get（）1）;
而不是简单
data.value;或data.value = data.value 1;
传递类时，数据封装很有用，并且您希望确保以受控方式修改值 . 但是，如果你有公共设置和获取功能，只需将值设置为传递的值，那么这比简单地传递公共数据结构有什么改进？
当我在类中创建私有结构时，我创建了该结构以将一组变量组织到一个组中 . 我希望能够在类范围内修改该结构，而不是获取该结构的副本并创建新实例 .
对我来说这阻止了有效使用用于组织公共变量的结构，如果我想要访问控制我会使用一个类 .
Eric Lippert先生的例子有几个问题 . 设法说明结构被复制以及如果你不小心这可能是一个问题 . 看一下这个例子，我认为它是一个糟糕的编程习惯，而不是结构或类的问题 .
结构应该只有公共成员，不应该要求任何封装 . 如果它确实那么它真的应该是一个类型/类 . 你真的不需要两个构造来说同样的事情 .
如果你有一个封闭结构的类，你可以在类中调用一个方法来改变成员结构 . 这就是我作为一个良好的编程习惯所做的事情 .
适当的实施如下 .
看起来这是编程习惯的问题，而不是struct本身的问题 . 结构应该是可变的，这就是想法和意图 .
变化的结果表现如预期：
1 2 3按任意键继续 . . .
可变数据有许多优点和缺点 . 百万美元的劣势是走样 . 如果在多个地方使用相同的值，并且其中一个更改了它，那么它似乎会神奇地改变为正在使用它的其他地方 . 这与竞争条件有关，但不相同 .
百万美元的优势有时是模块化的 . 可变状态允许您隐藏不需要了解它的代码中的更改信息 .
The Art of the Interpreter详细介绍了这些权衡，并给出了一些例子 .
如果使用得当，我不相信它们是邪恶的 . 我不会把它放在我的 生产环境 代码中，但我想做类似于结构化单元测试模拟的东西，其中结构的生命周期相对较小 .
使用Eric示例，也许您想要创建该Eric的第二个实例，但要进行调整，因为这是测试的性质（即复制，然后修改） . 如果我们只是将Eric2用于测试脚本的其余部分，那么Eric的第一个实例会发生什么并不重要，除非您计划将他用作测试比较 .
这对于测试或修改浅层定义特定对象（结构点）的遗留代码非常有用，但是通过使用不可变结构，这可以防止它的使用烦人 .