Collection.RemoveAt(Int32)与Collection.RemoveItem(Int32)方法的差异及设计缘由探究

这个问题问得非常好！这其实是.NET集合框架中模板方法模式的经典应用，背后有着清晰的设计逻辑，绝非历史遗留代码。咱们一步步拆解：

核心设计逻辑：模板方法模式 #

这两个方法的分工是典型的模板方法实现——把通用的、不可变的逻辑和可定制的行为分离开：

• 公共的非虚方法 RemoveAt(int index) 负责处理所有集合都必须遵守的通用安全校验：
  • 检查集合是否为只读状态，如果是则抛出异常
  • 验证索引是否在合法范围内（0 ≤ index < Count），越界则抛出参数异常
  • 确保所有调用入口都经过一致的校验逻辑
• 当这些校验通过后，它会把实际的元素移除操作委托给受保护的虚方法 RemoveItem(int index)。

这种设计带来两个关键好处：

1. 契约一致性：无论子类如何定制移除逻辑，所有调用 RemoveAt 的代码都会经过相同的校验步骤。不会出现子类跳过索引检查、忽略只读状态的情况，保证了集合的安全性和行为一致性。
2. 扩展友好性：自定义集合的开发者只需要专注于移除元素的具体逻辑（比如移除时触发变更事件、更新关联数据、记录操作日志等），不用重复编写那些通用的校验代码，大大降低了子类的实现成本。

适用场景 #

• 使用 RemoveAt：当你作为集合的使用者，需要移除指定索引的元素时，直接调用公共的 RemoveAt 方法即可。它会帮你处理所有必要的合法性检查，安全可靠，不用自己判断索引是否越界或者集合是否只读。
• 重写 RemoveItem：当你作为集合的开发者，要自定义 Collection<T> 的子类时，如果需要改变元素移除的具体行为，就重写 RemoveItem 方法。比如：

  public class ObservableCollection<T> : Collection<T>
  {
      public event NotifyCollectionChangedEventHandler CollectionChanged;
  
      protected override void RemoveItem(int index)
      {
          T removedItem = this[index];
          base.RemoveItem(index);
          // 触发集合变更事件
          CollectionChanged?.Invoke(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove, removedItem, index));
      }
  }
  

  这里子类只需要关注触发事件的逻辑，校验工作已经由 RemoveAt 完成了。

这是历史遗留代码吗？ #

完全不是！这种"公共非虚方法调用受保护虚方法"的模式在.NET框架中非常普遍，比如 Collection<T> 的 Add/Insert/SetItem 等方法都遵循同样的设计。它是经过深思熟虑的架构选择，既保证了基类的行为稳定性，又给子类留下了足够的扩展空间。

内容的提问来源于stack exchange，提问作者Christopher Edwards