我应该使用结构还是类？

Question

我陷入了经典的设计困境。我正在编写一个 C# 数据结构，用于包含值和测量单位元组（例如 7.0 毫米），我想知道是否应该使用引用类型或值类型。

结构的好处应该是减少堆操作，从而使我在表达式中获得更好的性能，并减轻垃圾收集器的压力。这通常是我对像这样的简单类型的选择，但在这种具体情况下存在缺点。

元组是相当通用的分析结果框架的一部分，其中根据结果值的类型，结果在 WPF 应用程序中以不同的方式呈现。 WPF 及其所有数据模板、值转换和模板选择器可以很好地处理这种弱类型。这意味着如果我的元组表示为结构体，则该值将经历大量装箱/拆箱。事实上，元组在表达式中的使用相对于拳击场景中的使用来说是次要的。为了避免所有的拳击，我考虑将我的类型声明为一个类。关于结构体的另一个担忧是，WPF 中的双向绑定可能存在缺陷，因为在代码中的某个位置获得元组的副本而不是引用副本会更容易。

我还有一些方便的运算符重载。我可以使用重载的比较运算符来比较毫米和厘米，而不会出现任何问题。但是，如果我的元组是一个类，我不喜欢重载 == 和 != 的想法，因为约定是 == 和 != 是引用类型的 ReferenceEquals（与 System.String 不同，这是另一个经典讨论）。如果 == 和 != 被重载，有人会编写 if (myValue == null) 并在有一天 myValue 变为 null 时得到一个讨厌的运行时异常。

另一方面是，C# 中没有明确的方法（与 C++ 等不同）来区分代码使用中的引用类型和值类型，但语义却非常不同。我担心我的元组（如果声明了结构）的用户假设该类型是一个类，因为大多数自定义数据结构都是并且假设引用语义。这是为什么人们应该更喜欢类的另一个论点，因为那是用户所期望的并且没有“。” /“->”来区分它们。一般来说，除非我的探查器告诉我使用结构，否则我几乎总是使用类，因为类语义是其他程序员最有可能期望的，而 C# 无论是一件事还是另一件事都只有模糊的提示。

所以我的问题是：

在决定应该价值还是参考时，我还应该考虑哪些其他因素？

在任何情况下，类中的 == / != 重载是否合理？

程序员承担一些事情。大多数人可能会认为所谓“点”的东西是一种值类型。如果您阅读一些带有“UnitValue”的代码，您会假设什么？

根据我的使用描述，您会选择什么？

Answer 1

结构的好处应该是减少堆操作，从而使我在表达式中获得更好的性能，并减轻垃圾收集器的压力

在没有任何上下文的情况下，这是一种巨大且危险的过度概括。结构不会自动符合堆栈的条件。当（且仅当）结构体的生命周期和暴露不会扩展到声明它的函数之外、它不会被装箱在该函数内，并且可能还有许多其他标准不满足时，才可以将结构体放置在堆栈上立即浮现在脑海中。这意味着将其作为 lambda 表达式或委托的一部分意味着它无论如何都会存储在堆上。 重点是不必担心，因为 99.9% 的可能性您的瓶颈在其他地方。

至于运算符重载，没有什么可以阻止您（无论是在技术上还是在哲学上）在您的类型上重载运算符。虽然您在技术上是正确的，默认情况下，引用类型之间的相等比较在语义上等同于 object.ReferenceEquals，但这并不是一个万能的规则。关于运算符重载，需要记住两个基本事项：

1.)（从实际角度来看，这可能是最重要的）运算符不是多态的。也就是说，您将仅使用在类型上定义的运算符因为它们被引用，而不是因为它们实际存在。

例如，如果我声明一个类型 Foo ，它定义了一个始终返回 true 的重载 equals 运算符，那么我会这样做：

Foo foo1 = new Foo();
Foo foo2 = new Foo();
object obj1 = foo1;

bool compare1 = foo1 == foo2; // true
bool compare2 = foo1 == obj1; // false

即使 obj1 是实际上，在 Foo 的实例中，重载运算符并不存在于我引用存储在 obj1 引用中的实例的类型层次结构级别，因此它退回到参考比较。

2.) 比较操作应该是确定性的。使用重载运算符比较相同的两个实例应该不可能产生不同的结果。 实际上，这种要求通常会导致类型不可变（因为能够区分类中一个或多个值之间的差异，但从 equals 运算符获得 true是相当违反直觉的），但从根本上来说，它只是意味着您不应该能够更改实例中的状态值来更改比较操作的结果。如果在您的场景中能够改变一些实例状态信息而不影响比较结果是有意义的，那么您没有理由不这样做。这只是一个罕见的案例。

Answer 2

但是，如果我的元组是一个类，我不喜欢重载 == 和 != 的想法，因为约定是 == 和 != 是引用类型的 ReferenceEquals

不，约定略有不同：

（与 System.String 不同，这是另一个经典讨论）。

不，这是同样的讨论。

关键不在于类型是否是引用类型。 – 类型是否表现为值。对于 String 来说是这样，对于您想要重载 operator == 和 != 的任何类也应该如此。

在设计逻辑上是值的类型时，您只需要注意一件事：使其不可变（请参阅 Stack Overflow 上的其他讨论），并正确实现比较语义：

如果 == 和 != 被重载，有人会编写 if (myValue == null) 并在有一天 myValue 为 null 时得到一个讨厌的运行时异常。

不应该有异常（毕竟，(string)null == null 也不会产生异常！），这将是重载运算符实现中的一个错误。

Answer 3

我不确定 UI 代码中的值装箱/拆箱的性能损失应该是您在这里主要关心的问题。例如，与布局过程相比，这种性能影响很小。

事实上，您可以用另一种方式表达您的问题：您希望您的类型是可变的还是不可变的？我认为不变性符合你的规范。这是一个值，您自己说过，将其命名为 UnitValue。作为一名开发人员，我会很惊讶 UnitValue 不是一个值 ;) =>使用不可变结构

此外，null 对于测量没有任何意义。平等和比较也应该遵循衡量规则来实施。

不，我没有看到在您的情况下使用引用类型而不是值类型的相关理由。

Answer 4

在我看来，您的设计需要元组的值类型语义。 <7.0，毫米>应始终等于<7.0, mm>从程序员的角度来看。 <7.0，毫米>正是其各部分的总和并且没有自己的恒等式。其他一切我都会觉得很混乱。这种 if 也意味着不变性。

现在，是否使用结构或类实现此功能取决于性能以及是否必须支持每个元组的空值。如果您选择结构体，并且只需要在少数情况下支持 null，则可以不用 Nullable。

另外，您不能为您的元组提供一个用于显示目的的引用类型包装器吗？我不太熟悉 WPF，但我想这将消除所有的装箱操作。

Answer 5

包含值和测量单位元组的数据结构（例如 7.0 毫米）

听起来它具有值语义。该框架提供了一种创建具有值语义的类型的机制，即struct。用那个。

几乎您在问题的下一段中所说的所有内容，赞成和反对值类型都是基于它如何与运行时的实现细节交互的优化问题。由于这方面有利有弊，因此没有明显的效率赢家。由于如果不实际尝试就无法找到明显的效率获胜者，因此任何在这方面进行优化的尝试显然都为时过早。尽管我对那句话感到厌倦，即当有人试图让某些东西变得更快或更小时，过早的优化就被大肆传播，但它确实适用于此。

但有一件事与优化无关：

如果我的元组是一个类，我不喜欢重载 == 和 != 的想法，因为约定是 == 和 != 是引用类型的 ReferenceEquals

根本不正确。 默认是 == 和 != 处理引用相等，但这也是因为它是唯一有意义的默认值，无需更多了解类的语义。当 == 和 != 适合类语义时，应该重载，当引用相等是人们唯一关心的事情时，应该使用 ReferenceEquals。

如果 == 和 != 被重载，有人会编写 if (myValue == null) 并在有一天 myValue 为 null 时得到一个讨厌的运行时异常。

仅当 == 重载出现新手错误时。正常的方法是：

public static bool operator == (MyType x, MyType y)
{
  if(ReferenceEquals(x, null))
    return ReferenceEquls(y, null);
  if(ReferenceEquals(y, null))
    return false;
  return x.Equals(y);
}

当然，Equals 重载还应该检查参数是否为 null，如果是，则返回 false，以便人们直接调用它。当一个或两个值都为 null 时，通过默认 == 行为调用此方法甚至不会对性能产生重大影响，那么有什么可担心的呢？

另一方面，C# 中没有明确的方法（与 C++ 等不同）来区分代码使用中的引用类型和值类型，但语义却截然不同。

并不真地。就相等性而言，默认语义非常不同，但由于您将某些东西描述为具有值语义，因此倾向于将其作为值类型，而不是作为类类型。除此之外，可用的语义非常相似。这些机制在装箱、参考共享等方面可能有所不同，但这又回到了优化。

在任何情况下，类中的 == / != 重载是否合理？

我宁愿问，当对类来说这是明智的事情时，重载 == 和 != 是否合理？

至于我作为一名程序员对“UnitValue”的假设，我可能会假设它是一个结构，因为听起来应该是这样。但实际上，我什至不会假设，因为我大多不会关心，直到我用它做一些重要的事情，考虑到它听起来也应该是不可变的，是一个简化集（可变和可变之间的语义差异）引用类型和可变结构在实践中更重要，但这是一个显而易见的不可变结构）。

Answer 6

也许您可以从 Eric Lippert 最近发表的这篇博文。使用结构时要记住的最重要的事情是使它们不可变。这是一个有趣的Jon Skeet 的博客文章，其中可变结构可能会导致非常难以调试的问题。