最难忍受的痛苦，也许是想干一件事情而又不去干。——罗曼·罗兰
前言
本篇文章算是拾人牙慧吧，偶尔谷歌到一个能很好把collection framework design讲好的文档，一是为了总结提升，也是collection framework 的开篇，从设计入手，更透彻的理解这个framework的过去和现在。
参照文档是 美国卡内基梅隆大学的Principles of Software Construction这门课程中一节课的课件 - collections design.pdf，建议在看本篇文章前，静下心来通读一遍这个文档。
结合自己的理解对collection framework做一个总结。
设计目标
- 小且简单。
- 易扩展。
- 与之前存在的集合兼容（事实上也做到了，
Vector和Hashtable分别实现了List和Map接口）。 - 很强的相似性(这个是从易用性角度来考虑的，因为在学习东西的时候，相似的东西是不需要从头学起的，学习成本自然降低了很多，后续源码分析先纵向深入，再横向类比)。
API设计准则
- 通用性，避免使用固定集合元素（事实上使用泛型来实现）。
- 与旧API的兼容性（
Vector和Hashtable都分别做了重构）。
文档的重要性
越是基础性的框架，设计文档、API或者是使用性文档越是要通俗易懂，这样基础性框架才便于开发者使用。毕竟大家都不喜欢用黑盒子，至少不会使用自己不了解的东西。
特别注意五种文档的完备性：
- 设计文档
- 概览文档
- API文档 - 不仅仅是javadoc
- 使用教程文档
- jira list
使用者的意见
多去听取使用者的意见，不好理解不好用的东西，理解不了，用起来自然不爽。
上面说到框架设计应该注意的事项，下面来具体聊一下collection framework design。
框架概览
简言之，我理解有四部分组成：
- 层次分明的接口和抽象类。
- 接口和抽象类的通用实现或完全实现。
- 基础算法。
- 并发支持（默认是不支持并发的，后来添加了对集合的封装，但只是简单的包装，效率不高，尤其是随着并发技术的发展，并发粒度越来越小，提供了很多juc的集合实现，逐渐废弃了集合框架中的原来的并发集合）。
API实现
集合接口分为两组类型接口，分别为 java.util.Collection和 java.util.Map，Map接口的子类严格来说而不是真实的集合。但是，这些接口包含集合视图操作，使它们可以作为集合进行操作。
随着这么多年的积累迭代，collection framework经过十多年的迭代更新（不是截止到现在，而是java 8 ，2014年），最终接口如下。
Collection 的子接口
Collection 的子接口有：
java.util.Setjava.util.SortedSetjava.util.NavigableSetjava.util.Queuejava.util.concurrent.BlockingQueuejava.util.concurrent.TransferQueuejava.util.Dequejava.util.concurrent.BlockingDeque
Map的子接口
Map的子接口有：
java.util.SortedMapjava.util.NavigableMapjava.util.concurrent.ConcurrentMapjava.util.concurrent.ConcurrentNavigableMap
对并发的支持
如上，支持并发的接口都定义在 java.util.concurrent包下，如下：
java.util.concurrent.BlockingQueuejava.util.concurrent.TransferQueuejava.util.concurrent.BlockingDequejava.util.concurrent.ConcurrentMapjava.util.concurrent.ConcurrentNavigableMap
集合和算法效率问题
通用集合实现的效率问题，在后续源码分析过程中会使用大O标记法来讨论框架插入删除或查找等算法的复杂度。
总结
- 一个好的框架设计，不仅要符合API的设计原则，也要考虑易用性，兼容性。
- 多听取使用者的意见
- 不管是框架的开发者还是使用者，都应该注重文档的使用
最后，我们不是在聊集合的设计吗，是的，包括集合框架中关键的概念，在collections design.pdf中基本上都涉及到了，不做过多的说明，快去看这个文档吧。