c#如何实现自定义集合_c#自定义集合项目实例附完整源码

C#中实现自定义集合应优先继承Collection而非手写IEnumerable或IList，因其已封装索引、枚举、通知等逻辑，仅需重写InsertItem等虚方法即可添加业务约束，兼顾安全、简洁与数据绑定支持。

开门见山，先说一个核心结论：在C#里打造自定义集合，别再费劲从头手写 IEnumerable 或者简单封装数组了。更明智的做法，是优先考虑继承 Collection、List 或者直接实现 IList。为什么？因为它们已经为你铺好了路，把索引、枚举、事件通知这些底层且繁琐的逻辑都封装妥当了。这样一来，你就能把精力完全集中在业务规则的实现上。

为什么别直接实现 IEnumerable

不少开发者第一步就踩进了这个坑：兴致勃勃地去实现 GetEnumerator() 和 IEnumerator。结果呢？很快就会发现，从增删改查到集合计数，所有功能都得自己从头搭建。甚至连在 foreach 里用 yield return 这种看似简单的语法，都没法自动获得 Count 属性或索引器的支持。

更棘手的问题还在后面：当你使用LINQ方法（比如 Where、First）时，它们返回的是全新的集合实例。这意味着，你精心设计的自定义行为——例如“只允许添加偶数”这样的校验规则——在链式调用的过程中就悄无声息地丢失了。

• 本质上，IEnumerable 只是一个只读遍历的契约，它本身不提供任何修改集合内容的能力。
• 如果退而求其次，手动实现完整的 IList，你需要重写的成员超过20个，极其容易遗漏 InsertItem、SetItem 这类关键性的钩子方法。
• 对于需要界面交互的场景，WPF或WinForms的数据绑定机制严重依赖 INotifyCollectionChanged 接口来通知更新。如果只实现一个“裸”的 IEnumerable，界面将无法感知集合的变化。

用 Collection 快速实现校验与拦截

那么，有没有既安全又省力的捷径？答案是肯定的。Collection 就是微软为此提供的“开箱即用”型基类。它的设计非常巧妙：将所有核心的增删改操作，都拆解成了独立的虚方法（例如 InsertItem、RemoveItem、SetItem、ClearItems）。你的任务变得异常简单——只需要重写那些需要介入业务逻辑的方法即可，其他行为全部交给基类默认处理。

举个例子，如果要创建一个“只接受正整数”的集合，代码可以如此简洁：

public class PositiveIntCollection : Collection
{
    protected override void InsertItem(int index, int item)
    {
        if (item <= 0) throw new ArgumentException("只允许添加正整数");
        base.InsertItem(index, item);
    }
protected override void SetItem(int index, int item)
{
    if (item <= 0) throw new ArgumentException("只允许设置正整数");
    base.SetItem(index, item);
}
}

你完全不需要操心如何重写 GetEnumerator —— 继承自基类的实现，让它天然就支持 foreach 遍历和所有LINQ操作。
所有修改集合的入口（无论是通过 Add、Insert 方法，还是直接使用索引器 [i] = x）都会被统一拦截，确保业务规则无一遗漏。
如果你需要在集合变化时执行额外操作（比如记录日志或触发UI更新），只需覆写相应的虚方法（如 ClearItems）并触发自定义事件即可。


何时才应该手动实现 IList？
既然继承基类如此方便，那还有手动实现接口的必要吗？当然有，但场景非常特定。通常只有两种情况值得你迎难而上：一是对性能有极致要求的场景（例如实现固定大小的环形缓冲区）；二是需要完全控制内存布局（比如将集合直接映射到一段非托管内存或数组）。除此之外，手动实现 IList 多半是自寻烦恼。
这里有个典型的反面教材：有人曾试图实现一个“自动跳过null元素”的 IList。结果陷入困境：Count 属性应该返回列表的总长度，还是非空元素的数量？索引器 this[0] 应该返回第一个非空元素，但如果第一个元素就是null，是否应该抛出异常？这违背了 IList 接口的核心契约——即 Count 与索引器的语义必须严格一致。

IList 明确要求 Count 属性的计算必须是常数时间复杂度O(1)，不能每次调用都重新遍历计数。
索引器 this[i] 必须能在O(1)时间内返回列表中第i个“物理位置”上的元素，不能动态跳过某些元素（如null）后重新编排索引。
如果你的本意是实现一个“过滤”视图，那么直接使用LINQ的 Where(x => x != null) 反而更安全、更符合开发者的直觉。


完整可用的轻量级实例（含源码要点）
理论说了这么多，来看一个能直接上手的例子。下面是一个兼具“唯一性约束”和“自动排序”的整数集合，核心代码仅30行左右，可以直接复制到.NET 6及以上版本的项目中运行：
public class SortedUniqueIntCollection : Collection
{
    private readonly SortedSet _inner = new();
public override int Count => _inner.Count;
protected override void InsertItem(int index, int item)
{
    if (_inner.Add(item)) base.InsertItem(index, item);
    else throw new InvalidOperationException($"重复值 {item} 不允许插入");
}
protected override void RemoveItem(int index)
{
    _inner.Remove(this[index]);
    base.RemoveItem(index);
}
protected override void ClearItems() {
    _inner.Clear();
    base.ClearItems();
}
}
需要特别注意的是，这个例子里的 _inner（一个 SortedSet）仅仅用于辅助实现去重和快速查找，真正的数据存储仍然在基类 Collection 内部的 Items 属性（其类型是 List）中。因此，当你使用 foreach 遍历时，元素的顺序取决于它们被插入的先后顺序，而非排序顺序。
这就引出了一个关键的权衡点：如果你希望遍历时也能严格按照排序顺序进行，那么继承 Collection 的路径可能就不太适合了。此时，你可能需要转而封装 SortedSet，并手动实现 IEnumerable 和 IReadOnlyList 等接口。这个细微但重要的区别，在不少文档和教程中常常被忽略，值得在实际开发中仔细考量。