返回只读对象的最佳实践

我对C＃中的OOP有“最佳实践”问题（但它适用于所有语言）。

考虑使库类具有要通过属性访问器公开的对象，但是我们不希望公众（使用此库类的人）对其进行更改。

class A
{
    // Note: List is just example, I am interested in objects in general.
    private List<string> _items = new List<string>() { "hello" }

    public List<string> Items
    {
        get
        {
            // Option A (not read-only), can be modified from outside:
            return _items;

            // Option B (sort-of read-only):
            return new List<string>( _items );

            // Option C, must change return type to ReadOnlyCollection<string>
            return new ReadOnlyCollection<string>( _items );
        }
    }
}

显然，最好的方法是“选项C”，但是很少有具有ReadOnly变体的对象（当然，没有用户定义的类具有它）。

如果您是A类的用户，您是否希望更改为

List<string> someList = ( new A() ).Items;

传播到原始（A）对象？还是返回一个克隆（如果它在注释/文档中是这样写的）可以吗？我认为这种克隆方法可能会导致很难跟踪的错误。

我记得在C ++中我们可以返回const对象，并且您只能在其上调用标记为const的方法。我想C＃中没有这样的功能/样式？如果不是，为什么不包括呢？我相信这称为const正确性。

但是，我的主要问题还是关于“您会期望什么”或如何处理选项A与B。

除了@Jesse的答案外，这是集合的最佳解决方案：总体思路是设计A的公共接口，使其仅返回

• 值类型（如int，double，struct）

• 不变的对象（例如“字符串”或用户定义的类，它们仅提供只读方法，就像您的类A）

• （仅在必须时）：对象副本，如“选项B”所示

IEnumerable<immutable_type_here> 本身是不可变的，因此这只是上述情况的特例。

还要注意，您应该对接口进行编程，并且总的来说，您想从该属性返回的是IEnumerable<string>。A List<string>有点不可以，因为它通常是易变的，我将进一步说，ReadOnlyCollection<string>作为ICollection<string>感觉的实现者，它好像违反了Liskov替代原理。

我曾遇到过类似的问题，下面是我的解决方案，但这实际上仅在您也控制库的情况下才有效：

从您的课程开始 A

public class A
{
    private int _n;
    public int N
    {
        get { return _n; }
        set { _n = value; }
    }
}

然后仅从属性的get部分（和任何读取方法）派生出一个接口，并让A实现

public interface IReadOnlyA
{
    public int N { get; }
}
public class A : IReadOnlyA
{
    private int _n;
    public int N
    {
        get { return _n; }
        set { _n = value; }
    }
}

然后，当然，当您要使用只读版本时，简单的转换就足够了。确实，这就是解决方案C所要解决的问题，但是我想我会提供实现它的方法

对于发现此问题但仍对答案感兴趣的任何人-现在有另一种方法可供选择ImmutableArray<T>。这些都是几点为什么我认为这是更好，然后IEnumerable<T>或者ReadOnlyCollection<T>：

• 它明确指出它是不可变的（表达性API）
• 它清楚地表明集合已经形成（换句话说，它不是很懒惰地初始化，可以多次遍历它）
• 如果项目的数量是已知的，它没有隐藏knowlegde喜欢IEnumerable<T>做
• 因为客户不知道该程序的实现是什么，IEnumerable或者IReadOnlyCollect他/她不能假定它永远不会更改（换句话说，不能保证一个集合的项目没有更改，而对该集合的引用保持不变）

另外，如果APi需要通知客户端有关集合中的更改，我会将事件作为单独的成员公开。

请注意，我并不是说IEnumerable<T>总体上是不好的。在将collection作为参数传递或返回延迟初始化的collection时，我仍然会使用它（在这种情况下，隐藏项目计数是有意义的，因为尚不知道）。