使用struct的好处是在表达式中减少堆操作,提高性能,并减轻垃圾收集器的压力。对于这种简单类型,这通常是我的选择,但在这种具体情况下存在缺点。
该元组是相当通用的分析结果框架的一部分,在WPF应用程序中,根据结果值的类型以不同的方式呈现结果。 WPF非常擅长处理这种弱类型,具有所有的数据模板,值转换和模板选择器。这意味着如果我的元组表示为struct,则该值将经历大量装箱/拆箱。实际上,元组在表达式中的使用将比在装箱场景中的使用要少得多。为了避免所有装箱,我考虑将我的类型声明为类。另一个关于struct的担忧是,在WPF中进行双向绑定可能会有陷阱,因为很容易在代码中复制元组的副本而不是引用副本。
我还有一些方便的运算符重载。我可以使用重载的比较运算符轻松比较毫米和厘米。但是,如果我的元组是一个类,我不喜欢重载==和!=的想法,因为惯例是对于引用类型,==和!=是ReferenceEquals(与System.String不同,这是另一个经典的讨论)。如果重载==和!=,有人会写if(myValue == null),并在某一天myValue变为空时得到一个令人不快的运行时异常。
还有另一个方面,即在C#中没有明确的方法(与例如C ++不同)来区分引用和值类型在代码使用中,但语义非常不同。我担心我的元组的用户(如果声明struct)会假设该类型是类,因为大多数自定义数据结构都是,并且假定引用语义。这是另一个论据,为什么应该优先使用类,因为这是用户所期望的,而且没有“.” /“ - >”来区分它们。通常情况下,除非我的分析器告诉我要使用struct,否则我几乎总是使用类,因为类语义是最有可能被其他程序员期望的,而C#只有模糊的提示,无论它是一件事还是另一件事。
所以我的问题是:
在决定是否使用值或引用时,我应该考虑哪些其他因素?
在任何情况下,是否可以证明在类中重载== /!=?
程序员会假设一些东西。大多数人可能会认为称为“Point”的东西是值类型。如果阅读带有“UnitValue”的代码,您会假设什么?
在我的使用描述中,您会选择什么?