Collection 类和它的使用
Collection 类和它的使用
我遇到了下面的代码：\n
var collection = new Collection();
\n我很少见到使用Collection类的情况，并且找不到关于它用途的太多信息。从.NET Framework源代码来看，它实际上只是一个围绕List的包装器，因为它存储了一个List成员字段。它的构造函数如下：\n
public Collection()
{
this.items = (IList) new List();
}
\n它还实现了IList接口。因此，你可以将Collection声明为：\n
IListcollection = new Collection ();
\n对我来说，这在功能上等同于创建一个List：\n
IListcollection = new List ();
\n那么，在自己的代码中，你何时会选择使用它而不是List呢？我看到它是其他.NET集合的基类，但为什么他们将其包含为公共具体类（而不是internal和/或abstract）呢？\n
\n关于可能重复的评论——相关问题的答案似乎表明Collection类应该用作基类。我真正不同的问题是：\n
- \n
- 在自己的代码中使用时，为什么不将List作为基类？
- 在自己的代码中，实例化新的Collection来替代List真的有意义吗？
- 如果它只是作为基类提供，为什么它不是抽象的？
\n
\n
\n
问题的出现原因是List类不适合在公共对象模型中使用，因为它不能被扩展，无法重写成员，并且具有许多在许多情况下不相关的成员。因此，建议使用Collection类代替List类。
解决方法是使用Collection类而不是List类来公开泛型集合。Collection类允许重写SetItem方法来在添加新项或更改现有项时接收通知。此外，使用Collection类还可以简化公共对象模型，并避免向外部暴露不必要的成员。
FxCop的规则CA1002也建议不要公开泛型List，并使用Collection类。根据FxCop规则，返回Collection而不是List有以下原因。
因此，Collection类的使用是为了解决List类在公共对象模型中的限制和不相关成员的问题。通过使用Collection类，可以更好地控制和管理泛型集合，并使公共对象模型更加简洁和简单。
Collection(T)类是许多其他集合类的基类。List类是一个速度优化的类，而Collection类则设计用于可扩展性。当查看Collection(T)的成员时，会发现它包含一些额外的受保护虚拟方法（如InsertItem），而List(T)类没有这些方法。实际上，我创建了一个Collection类的实例。我认为只有在方法签名中使用此类型作为参数时，才会使用它，这样可以避免方法与集合实现的紧耦合（如果可能的话）。
回答你的问题：
1. 我会将Collection(T)作为基类使用，因为这个类的意图是作为其他集合类型的基类使用。它提供了更多的灵活性（参见受保护的虚拟方法InsertItem、RemoveItem和SetItem）。
2. 当需要一个集合时，我会使用List(T)类的实例，因为它经过了速度优化。
3. 实际上，我想知道为什么他们没有将Collection(T)类定义为抽象类。
Collection
在MSDN文档中，Collection类提供了一些受保护的方法，可以在添加和删除项、清空集合或设置现有项的值时自定义其行为。这使得实现自定义集合变得更加容易。因此，开发者被鼓励扩展这个基类而不是创建自己的集合类。
如果在自己的代码中使用，为什么不使用List作为基类呢？Collection
对于仅仅初始化一个新的Collection来说，并没有太多意义。只有在需要将其作为实现自己逻辑的基类时才使用它。这取决于自己的业务需求。在日常开发工作中，现有的各种集合类型应该已经提供了所需的功能。有类型安全和非类型安全的集合，线程安全的集合，以及其他你可以想到的集合类型。但是，也许有一天需要实现一个在允许添加/更新/删除任何项之前执行某些有效性检查的集合类型，或者以特殊方式处理一个稀疏列表中的下一个项。你永远不知道客户可能会有什么需求。在这些情况下，创建自己的集合类型可能会有帮助。
关于为什么Collection类不是抽象的，这只是一个猜测，但我认为这是为了让你不必实现核心功能，而只需关注在基本功能上与之不同的地方实现自己的逻辑。抽象类可以有非抽象的虚方法，因此可以通过抽象类实现这个目的。