对不可变结构使用公共只读字段，而不是私有字段/公共 getter 对

Question

这是我第一次编写将用于广泛的几何计算的小型不可变结构。我很想使用public readonly 字段而不是private field/public getter 组合。

public struct Vector4
{
    public readonly float Angle, Velocity;

    // As opposed to:
    private float _Angle, _Velocity;
    public float Angle { get { return (this._Angle); } }
    public float Velocity { get { return (this._Velocity); } }

    public Vector4 (float angle, float velocity)
    {
        // Once set in the constructor, instance values will never change.
        this.Angle = angle;
        this.Velocity = velocity;
    }
}

它看起来更干净，并消除了额外的层（吸气剂）。除了使用公共字段是不好的做法之外，以这种方式使用公共只读字段是否有任何负面影响？

注意，我们只讨论值类型。例如，数组会暴露要被调用代码覆盖的元素。

更新：

感谢所有输入。在这种不使用数据绑定等的情况下，使用public readonly 字段似乎没有缺点。在我的基准测试中，执行时间减少了 70%，这是一个大问题。以 .NET 4 为目标，我希望编译器能够内联 getter-only 属性。基准测试当然是在没有附加调试器的情况下在发布配置中测试的。

Answer 1

.NET Framework 设计指南say about fields：

请勿提供公开或受保护的实例字段。

这是一个强有力的声明。这不是一个绝对的规则，但它非常接近指南的introduction：

在某些情况下，良好的库设计要求您违反这些设计准则。这种情况应该很少见，重要的是您必须有明确且令人信服的理由做出决定。

那么这对您的代码意味着什么？一个关键问题是您的代码的受众。您是否正在编写指南定义的“框架”，它是“扩展 .NET Framework 并与之交互的库”之一？

如果您正在编写一个框架，那么您会遇到大多数代码所没有的约束。许多其他代码将取决于您的代码，对重大更改很敏感，并且需要与您的 DLL 的二进制兼容性。这就是为什么属性对框架很重要的原因。如果更高版本的框架需要向 getter 或 setter 添加逻辑，则从字段更改为属性会破坏二进制兼容性。

大多数代码不是框架的一部分。依赖关系很少，如果有一个简单的重大更改，可以很容易地修复。例如，依赖代码可能使用out 或ref 参数中的字段。如果稍后将该字段更改为属性以使其具有某些逻辑，则修复损坏的代码通常没什么大不了的。编译器将引导您解决问题。同样，也不需要二进制兼容性。如果不重新编译依赖项，您将永远不会放入更新的 DLL。

对于非框架代码，如果以后将其更改为属性的机会很小，则最好使用字段。字段更灵活，属性更佳，在某些情况下更快。

Answer 2

自动属性可能会有所帮助。

public struct Vector4
    {
    public float Angle { get; private set; }
    public float Velocity { get; private set; }

    public Vector4(float angle, float velocity) : this()
        {
        // Once set in the constructor, instance values will never change.
        this.Angle = angle;
        this.Velocity = velocity;
        }
    }

[注意：已更新以使其可以编译 - 感谢 Lasse V. Karlsen 指出这一点]

请注意，这与具有支持字段的属性完全相同，只是您让编译器选择其名称（这将是一些“无法说出”的字符串）。

您对属性有什么困扰？如果是详细程度，则使用上面的 auto 属性。如果您关心性能，那么您是否衡量过属性与字段的影响？

有趣的是，在他的书CLR via C# 中，Jeffrey Richter 对属性相当“失望”，表示他希望它们没有包含在 CLR 中。他说他更喜欢明确使用 getXXX 和 setXXX 方法。他认为属性语法令人困惑。就我个人而言，看到 Java 代码的工作方式与此完全一样，我更喜欢属性语法。

我认为还值得一提的是readonly 也可能令人困惑。在这种情况下，它是明确的，因为我们一直在处理值类型，并且readonly'按照它在锡上所说的那样做'。然而，如果这些是引用类型，那么readonly 只保护引用——也就是说，字段必须始终引用同一个对象，但如果被写入允许被引用的对象本身可能会发生变异。我怀疑许多没有经验的程序员会被这种微妙之处绊倒。

鉴于您衡量的性能优势，我认为您有合理的理由使用公共只读字段，这是一个判断电话。权衡是你允许你的类型的消费者与你的结构的内部紧密耦合，基本上牺牲了封装。对于这种受控条件下的简单类型并具有经过验证的性能优势，这可能是合理的。

Answer 3

诸如“Prefer public properties over public fields”之类的准则是准则，而不是规则。

在某些情况下，使用字段的优点可能超过缺点。事实上，Rico Mariani 很好地说明了一个这样的场景，在我看来这和你的很像：

• Performance Quiz #11: Ten Questions on Value-Based Programming
• Performance Quiz #11: Ten Questions on Value-Based Programming : Solution

他关于使用字段而不是属性的主要论点是，Point、Vector 和 Vertex 这样的原语通常没有非法值，因此几乎不需要或不需要添加 getter/setter 层。

他还为具有 可变 字段提出了很好的论据，但无论如何这不是你的情况。

但我想自己补充一点供您考虑：您的类会被用于数据绑定吗？数据绑定仅适用于属性，不适用于字段。

Answer 4

在没有反射的纯 C# 中，在您的情况下几乎没有理由避免使用只读字段，我自己可能会选择只读字段。属性的大多数一般优势在这里并不适用。那就是……

任何使用反射来获取属性列表并作用于这些属性的东西，在未经修改的情况下将无法与字段（无论是否只读）一起使用。

特别是，将属性更改为字段可能会导致数据绑定停止工作。它将继续编译而没有任何问题，但它不再做你想做的事。如果您有任何此类代码，或者您预计将来会出现此类代码，则需要继续使用属性。