模板方法模式：解析 AbstractCollection 如何定义集合操作的变量骨架

在Ja va集合框架的庞大体系中，AbstractCollection 扮演着一个至关重要的角色。它并非一个功能完备的集合，而更像是一位总架构师，为所有集合操作勾勒出一个清晰的“骨架”。这个骨架的核心思想，正是设计模式中经典的“模板方法模式”——将不变的流程固化下来，把可变的行为留给具体实现去发挥。

它定义了什么骨架

打开AbstractCollection的源码，你会发现它虽然实现了Collection接口，但只强制要求子类完成两件事：

• iterator()：告诉我如何遍历你的元素。
• size()：告诉我你现在有多少个元素。

就这两样。剩下的所有方法，比如判断是否包含（contains()）、删除元素（remove()）、判断是否为空（isEmpty()）、转换成数组（toArray()）等等，全部都是基于这两个核心方法搭建起来的。

这形成了一个非常稳固的算法框架：无论底层数据结构是数组还是链表，是树还是哈希表，只要你能提供遍历方式和大小，上层操作就能统一进行。举个例子：

• isEmpty() 的实现简单到极致，直接看 size() == 0 就行，既安全又高效。
• contains(Object o) 就没那么幸运了，它必须老老实实地调用 iterator()，然后从头到尾遍历比对，时间复杂度注定是O(n)。
• remove(Object o) 同样依赖迭代器，先找到元素，再调用迭代器的 remove() 方法。这里有个关键点：如果子类提供的迭代器不支持删除操作，那么整个删除就会失败。

为什么说它是“变量骨架”而非完整实现

“骨架”这个词很形象。它固定了“要做什么”以及“大致的步骤”，但最关键的细节——也就是“变量”部分——完全交由子类决定。

• 遍历方式：iterator() 返回什么样的迭代器，直接决定了遍历的性能、是否线程安全，以及是否支持并发修改。
• 大小计算：size() 是实时计算还是维护一个计数器？这会影响 isEmpty() 和 toArray() 等方法的效率和一致性。
• 预留的“钩子”：最典型的例子是 add(E e) 方法。在AbstractCollection中，它的默认实现是直接抛出 UnsupportedOperationException。这就是一个预留的“钩子方法”（hook），明确告诉子类：“如果你想支持添加功能，就必须自己来重写我。”这完美体现了模板方法模式中“可变部分”的留白艺术。

正是这种设计，让ArrayList、LinkedList、HashSet这些底层实现天差地别的集合，能够复用同一套顶层的操作逻辑，各自只需专注于实现最核心的数据访问机制。

它和 AbstractList/AbstractSet 的关系

如果把AbstractCollection看作集合的“通用骨架”，那么AbstractList和AbstractSet就是在此基础上，针对特定语义的“专业化升级”。

• AbstractList：它明确了“有序、允许重复、支持索引访问”的列表语义。它不仅继承了遍历和大小控制，还预置了基于索引的 get(int index)、set(int index, E element) 等方法的模板，为ArrayList和LinkedList这样的具体列表铺平了道路。
• AbstractSet：它则强调了“无序、元素唯一”的集合语义。一个重要的体现是，它默认重写了 equals() 和 hashCode() 方法，确保两个集合的比较是基于元素内容而非对象引用，这符合数学上“集”的概念。

可以说，AbstractCollection定义了“一个集合如何被遍历和度量”，而它的子类们则决定了“它究竟是一个什么样的集合”。

实际开发中要注意什么

理解了它的设计精妙，但在实际编码中，直接继承AbstractCollection来创建自定义集合的情况并不多见，甚至可以说需要格外小心，因为这里有几个常见的“坑”：

• 默认的添加陷阱：如果你没有重写 add() 方法，却调用了它，等待你的将是 UnsupportedOperationException。这不是bug，而是设计如此。
• 迭代器权限不足：如果你的 iterator() 返回的迭代器不支持 remove() 操作，那么调用 remove(Object) 方法就会失败。它不会静默跳过，而是会抛出异常。
• 大小不一致的隐患：如果 size() 方法的返回值与迭代器实际遍历出的元素数量不一致（比如在并发环境下未正确同步），那么 toArray() 方法可能会分配错误大小的数组，甚至引发 ConcurrentModificationException。
• 性能天花板：所有基于迭代器遍历的方法（如 contains, remove）时间复杂度都是O(n)。如果你的集合需要频繁进行此类查询，这个骨架无法为你提供哈希查找或二分查找的优化，你需要更底层的设计。

因此，一个实用的建议是：当你需要自定义一个集合时，优先考虑继承AbstractList或AbstractSet，它们提供了更贴近具体需求的模板。如果确实需要从零开始定义一个全新的集合类型，或许直接实现Collection接口，并只精心实现你真正需要定制的那部分方法，反而是更清晰、更可控的选择。毕竟，AbstractCollection提供的这个“变量骨架”，更像是一个为框架内部大量复用而设计的精妙蓝图，而非给日常应用开发随意使用的积木。