Java调集接口综述[Java编程]

调集老是需求迭代的,我们确切需求探察调集合的每一个元素,所以调集接口都无一例外的担当了Iterable<T>接口 ,而该接口的唯一办法 :

可以返回一个全部调集接口都担当了的Iteraor接口,如此调集框架的全部子类都可以迭代显示其元素!

比方下:调集的根接口Collection担当了Iterator接口:

public interface Collection<E> extends Iterable<E>　　Collection 层次构造 中的根接口.Collection 表示一组对象,这些对象也称为 collection 的元素.一些 collection 答应有反复的元素,而另一些则不答应.一些 collection 是有序的,而另一些则是无序的.JDK 不供应此接口的任何直接 实现:它供应更具体的子接口（如 Set 和 List）实现.此接口普通用来传送 collection,并在需求最大广泛性的地方操作这些 collection.

包 (bag) 或多调集 (multiset)（大概包含反复元素的无序 collection）应当直接实现此接口.

全部通用的 Collection 实现类（普通通过它的一个子接口间接实现 Collection）应当供应两个“尺度”构造办法:一个是 void（无参数）构造办法,用于成立空 collection;另一个是带有 Collection 范例单参数的构造办法,用于成立一个具有与其参数相同元素新的 collection.实际上,后者答应用户复制任何 collection,以生成所需实现范例的一个等效 collection.固然无法强迫履行此约定（因为接口不能包含构造办法）,但是 Java 平台库中全部通用的 Collection 实现都顺从它.

此接口中包含的“破坏性”办法,是指可改正其所操作的 collection 的那些办法,假如此 collection 不支持该操作,则指定这些办法抛出 UnsupportedOperationException.假如是这样,那么在调用对该 collection 无效时,这些办法大概,但并不一定抛出 UnsupportedOperationException.比方,假如要增添的 collection 为空且不可改正,则对该 collection 调用addAll(Collection)办法时,大概但并不一定抛出非常.

一些 collection 实现对它们大概包含的元素有所限制.比方,某些实现禁止 null 元素,而某些实现则对元素的范例有限制.试图增添不合格的元素将抛出一个未经查抄的非常,普通是 NullPointerException 或 ClassCastException.试图查询能否存在不合格的元素大概抛出一个非常,大概只是简单地返回 false;某些实现将表现出前一种行为,而某些实现则表现后一种.较为常见的是,试图对某个不合格的元素履行操作且该操作的完成不会招致将不合格的元素插入 collection 中,将大概抛出一个非常,也大概操作成功,这取决于实现本身.这样的非常在此接口的标准中标志为“可选”.

此接口是 Java Collections Framework 的成员.

Collections Framework 接口中的很多办法是按照equals办法定义的.比方,contains(Object o)办法的标准声明:“当且仅当此 collection 包含至少一个满意 (o==null ? e==null :o.equals(e)) 的元素 e 时,才返回 true.”不该将此标准理解为它暗指调用具有非空参数 o 的 Collection.contains 办法会招致为肆意的 e 元素调用 o.equals(e) 办法.可随便对各种实现履行优化,只要避免调用 equals 便可,比方,通过首先对比两个元素的哈希码.（Object.hashCode()标准保证哈希码不相等的两个对象不会相等）.较为常见的是,各种Collections Framework 接口的实现可随便操纵底子Object办法的指定行为,而不管实现程序认为它能否符合.

调集Collection的父接口所返回的Iterator接口的意义:

public interface Iterator<E>

对调集举行迭代的迭代器.迭代器替换了 Java Collections Framework 中的 Enumeration.迭代器与列举有两点差别:迭代器答应调用方操纵定义杰出的语义在迭代期间从迭代器所指向的调集移除元素. 办法名称得到了改良.