c# - 持久集合和标准集合接口(interface)

Question

我正在实现一个持久化集合——为了论证，我们假设它是一个函数式语言中常见样式的单链表。

class MyList<T>
{
    public T Head { get; }
    public MyList<T> Tail { get; }

    // other various stuff
    // . . .
}

让这个类实现似乎很自然ICollection<T> ，因为它可以实现人们对 ICollection<T> 期望的所有正常行为，至少在粗略的范围内。但是这个类的行为和ICollection<T>之间有很多不匹配的地方。 .例如 Add() 的签名方法

void Add(T item);  // ICollection<T> version

假设添加将作为改变集合的副作用执行。但这是一个持久数据结构，因此 Add() 应该创建一个新列表并返回它。

MyList<T> Add(T item);  // what we really want

解决这个问题的最好方法似乎是只创建我们想要的版本，并生成接口(interface)中定义的版本的非功能性显式实现。

void ICollection<T>.Add(T item) { throw new NotSupportedException(); }
public MyList<T> Add(T item) { return new MyList<T>(item, this); }

但我对该选项有一些担忧:

1. 这会让用户感到困惑吗？我设想有人正在使用此类的场景，并发现在其上调用 Add() 有时会引发异常，有时会运行但不会像 ICollection 通常预期的那样修改列表，具体取决于关联的类型信息正在使用引用？

2. 在 (1) 之后，执行 ICollection<T>的 IsReadOnly大概应该返回 true。但这似乎与 Add() 与类的实例一起使用的其他地方的暗示冲突。

3. (2) 是否通过再次遵循显式实现模式以不混淆的方式解决，新版本返回 false显式实现返回 true ？或者这只是通过错误地暗示 MyList<T> 使情况变得更糟的 Add()方法是一个增变器？

4. 或者忘记尝试使用现有界面并创建一个单独的 IPersistentCollection<T> 会更好吗？派生自 IEnumerable<T> 的接口(interface)反而？

编辑 我更改了类的名称，并切换到使用 ICollection。我想关注对象的行为以及它与界面的关系。我只是以缺点列表作为一个简单的例子。我很欣赏这样的建议，即如果我要实现一个缺点列表，我应该尝试想出一个不那么令人困惑的名称，并且应该避免实现 IList，因为该接口(interface)旨在用于快速随机访问，但它们有些无关紧要。

我想问的是其他人如何看待框架中内置的只读(或不可变)集合的语义与实现与接口(interface)所描述的等效行为的持久集合之间的紧张关系，仅在功能上而不是通过变异的副作用。

Answer 1

Will implementing IList<T> be confusing?

是的。尽管在某些情况下 IList<T> 的实现抛出——比如说，当你试图调整列表的大小时，但它的实现是一个数组——我会发现 IList<T> 很困惑无法以任何方式改变并且没有快速随机访问。

Should I implement a new IPersistentList<T>?

那要看有没有人会用了。您所在类(class)的消费者是否可能有六种不同的 IPL<T> 实现？从中选择？我认为制作一个仅由一个类实现的接口(interface)没有意义；只需使用该类即可。

WPF's ItemsControl can get better performance if its ItemsSource is an IList<T> instead of an IEnumerable<T>.

但是你的持久链表无论如何不会有快速随机访问。