Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

数组类Array是Java中最基本的一个存储结构。它用于存储一组连续的对象或基本类型的数据。其中的元素的类型必须相同。

Array是最有效率的一 种：

1、效率高，但容量固定且无法动态改变。 Array还有一个缺点是，无法判断其中实际存有多少元素，length只是告诉我们Array的容量。

2、Java中有一个Arrays类，专门用来操作Array，提供搜索、排序、复制等静态方法。 equals()：比较两个Array是否相等，Array拥有相同元素个数，且所有对应元素两两相等。 fill()：将值填入Array中。 sort()：用来对Array进行排序。 binarySearch()：在排好序的Array中寻找元素。 System.arraycopy()：Array的复制。

Java Collections Framework成员主要包括两种类型，即：Collection和Map类型。 在Java中提供了Collection和Map接口。其中List和Set继承了Collection接口；Vector、ArrayList、 LinkedList三个类实现List接口，HashSet、TreeSet实现Set接口，HashTable、HashMap、 TreeMap实现Map接口。由此可见，Java中用8种类型的基本数据结构来实现其Collections Framework；下面分别进行介绍。

Vector：基于Array的List，性能也就不可能超越Array，并且Vector是"sychronized"的，这个也是Vector和ArrayList的唯一的区别。

ArrayList：同Vector一样是一个基于Array的，但是不同的是ArrayList不是同步的。所以在性能上要比Vector优越一些，但 是当运行到多线程环境中时，可需要自己在管理线程的同步问题。从其命名中可以看出它是一种类似数组的形式进行存储，因此它的随机访问速度极快。

LinkedList：LinkedList不同于前面两种List，它不是基于Array的，所以不受Array性能的限制。它每一个节点（Node） 都包含两方面的内容：

1、节点本身的数据（data）；

2、下一个节点的信息（nextNode）。所以当对LinkedList做添加，删除动作的时候 就不用像基于Array的List一样，必须进行大量的数据移动。只要更改nextNode的相关信息就可以实现了所以它适合于进行频繁进行插入和删除操 作。这就是LinkedList的优势。Iterator只能对容器进行向前遍历，而 ListIterator则继承了Iterator的思想，并提供了对List进行双向遍历的方法。

List总结：

1、所有的List中只能容纳单个不同类型的对象组成的表，而不是Key－Value键值对。例如：[ tom,1,c ]；

2、所有的List中可以有相同的元素，例如Vector中可以有 [ tom,koo,too,koo ]；

3、所有的List中可以有null元素，例如[ tom,null,1 ]；

4、基于Array的List（Vector，ArrayList）适合查询，而LinkedList（链表）适合添加，删除操作。

HashSet：虽然Set同List都实现了Collection接口，但是他们的实现方式却大不一样。List基本上都是以Array为基础。但是 Set则是在HashMap的基础上来实现的，这个就是Set和List的根本区别。HashSet的存储方式是把HashMap中的Key作为Set的 对应存储项，这也是为什么在Set中不能像在List中一样有重复的项的根本原因，因为HashMap的key是不能有重复的。HashSet能快速定位 一个元素，但是放到HashSet中的对象需要实现hashCode()方法0。

TreeSet则将放入其中的元素按序存放，这就要求你放入其中的对象是可排序的，这就用到了集合框架提供的另外两个实用类Comparable和 Comparator。一个类是可排序的，它就应该实现Comparable接口。有时多个类具有相同的排序算法，那就不需要重复定义相同的排序算法，只要实现Comparator接口即可。TreeSet是SortedSet的子类，它不同于HashSet的根本就是TreeSet是有序的。它是通过SortedMap来实现的。

Set总结：

1、Set实现的基础是Map（HashMap）；

2、Set中的元素是不能重复的，如果使用add(Object obj)方法添加已经存在的对象，则会覆盖前面的对象； Set里的元素是不能重复的，那么用什么方法来区分重复与否呢? 是用==还是equals()? 它们有何区别? Set里的元素是不能重复的，即不能包含两个元素e1、e2（e1.equals（e2））。那么用iterator()方法来区分重复与否。 equals()是判读两个Set是否相等。==方法决定引用值(句柄)是否指向同一对象。

HashMap、TreeMap、Hashtable：

1、HashMap也用到了哈希码的算法，以便快速查找一个键，TreeMap则是对键按序存放，因此它有一些扩展的方法，比如 firstKey(),lastKey()等。

2、Hashtable：不允许空（null）键（key）或值（value），Hashtable的方法是Synchronize的，在多个线程访问 Hashtable时，不需要自己为它的方法实现同步，而HashMap 就必须为之提供外同步。 Hashtable和HashMap采用的hash/rehash算法都大概一样，所以性能不会有很大的差异。

3、HashMap和Hashtable的区别：HashMap是Hashtable(线程案例的)的轻量级实现（非线程安全的实现），他们都完成了Map接口。主要区别在于HashMap允许空（null）键（key）或值（value）,非同步，由于非线程安全，效率上可能高于Hashtable。

Map总结：

是一种把键对象和值对象进行关联的容器，Map有两种比较常用的实现： HashTable、HashMap和TreeMap。

一、在单元测试领域里，JUnit可以说是王者，它不但精致，而且使用方便。最后有些时间，把JUnit源码读读，顺便复习下设计模式 ：）

二、参考文章
        在深入看代码之前，先看下面的文章，对JUnit有一个基本的了解后，看代码会更有目的性。
        JUnit官方网站：http://www.junit.org/ 
        分析 JUnit 框架源代码： http://www.ibm.com/developerworks/cn/java/j-lo-junit-src/
        JUnit A cook's tour:  http://junit.sourceforge.net/doc/cookstour/cookstour.htm

三、核心架构
        我分析的源码的版本是JUnit 3.8.2，这个版本相对简略，把核心思想表现出来了，没有4.X版本那么多附加的功能
        
        JUnit是一个模式密集型的框架，主要用组合模式、模样方法、观察者模式、参数收集方法、命令模式、装饰者模式和适配器模式。其中核心是  前三种


核心类之间的关系


Test、TestCase和TestSuit构成了测试框架的基础，它们用composite模式组合在一起，使得客户端可以将对象的集合以及个别的对象(TestCase)一视同仁.TestRusult用来保存测试结果，和TestListner组成observer模式，支持文本界面、图形界面和 Eclipse 集成组件三种监听器
和JUnit A cook's tour中提到的模式图很相似

类与类之间的关系在此就不作解释了，可以看看参考文章。有兴趣的朋友，欢迎一起讨论 ：）

多用组合，少用继承

针对接口编程，不针对实现编程

为交互对象之间的松耦合设计而努力

类应该对扩展开放，对修改关闭

只和朋友交谈

别找我，我会找你

类应该只有一个改变的理由

38、只针对不正常的条件使用异常
异常只应该被用于不正常的条件，它们永远不应该被用于不正常的条件
设计API启示：一个良好的API不应该强迫它的客户为了正常的控制流而使用异常。对于边界的判断常用的有两种方法：状态测试方法和可被识别的返回值

40、对于可以恢复的条件使用被检查的异常，对于程序错误使用运行时异常
 Thowable（可抛出异常）有三种结构：被检查的异常(checked exception)、运行时异常（run-time exception)和错误(error)
如果期望调用者能够恢复，那么，对于这样的条件应该使用被检查的异常
运行时异常和错误，不需要也不应该是被捕获的抛出物
用运行时异常来指明程序错误
对于被检查的异常，提供一些辅助方法是非常重要的，通过这些方法，调用者可以获得一些有助于恢复的信息

41、避免不必要地使用被检查的异常

42、尽量使用标准异常
      

43、抛出的异常要适合于相应的抽象
高层的实现应该捕获低层的异常，同时导出一个可以按照高层抽象进行解释的---异常转译
低层的异常对于调试该异常被拨出的情形非常有帮助的话，可以使用异常链接。即低层的异常被高层的异常保存起来，并且高层的异常提供一个公有的访问方法来获得低层异常

44、每个异常的抛出都必须有文档

45、在细节消息中包含失败--捕获信息
为了捕获失败，一个异常的的字符串表示应该包含所有“对异常有贡献”的参数和域的值
在异常构造函数中以参数形式引入这些信息

46、努力使失败保持原子性
一个失败方法调用应该使用对象保持“它在被调用之前的状态” ---failure atomic
几种解决方法：在执行操作之前检查参数的有效性
调整计算机过程，使得任何可能会失败的计算部分发生在对象状态被修改之前
编写一段恢复代码
在对象上临时都拷贝一份，当操作完成之后把临时拷贝中的结果复制给原来的对象。如：Collections.sort

47、不要忽略异常
写上try catch块