public interface Collection<E>
- extends Iterable<E>
The root interface in the collection hierarchy. A collection represents a group of objects, known as its elements. Some collections allow duplicate elements and others do not. Some are ordered and others unordered. The JDK does not provide any direct implementations of this interface: it provides implementations of more specific subinterfaces like Set and List. This interface is typically used to pass collections around and manipulate them where maximum generality is desired.
Bags or multisets (unordered collections that may contain duplicate elements) should implement this interface directly.
All general-purpose Collection implementation classes (which typically implement Collection indirectly through one of its subinterfaces) should provide two "standard" constructors: a void (no arguments) constructor, which creates an empty collection, and a constructor with a single argument of type Collection, which creates a new collection with the same elements as its argument. In effect, the latter constructor allows the user to copy any collection, producing an equivalent collection of the desired implementation type. There is no way to enforce this convention (as interfaces cannot contain constructors) but all of the general-purpose Collection implementations in the Java platform libraries comply.
The "destructive" methods contained in this interface, that is, the methods that modify the collection on which they operate, are specified to throw UnsupportedOperationException if this collection does not support the operation. If this is the case, these methods may, but are not required to, throw an UnsupportedOperationException if the invocation would have no effect on the collection. For example, invoking the addAll(Collection) method on an unmodifiable collection may, but is not required to, throw the exception if the collection to be added is empty.
Some collection implementations have restrictions on the elements that they may contain. For example, some implementations prohibit null elements, and some have restrictions on the types of their elements. Attempting to add an ineligible element throws an unchecked exception, typically NullPointerException or ClassCastException. Attempting to query the presence of an ineligible element may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter. More generally, attempting an operation on an ineligible element whose completion would not result in the insertion of an ineligible element into the collection may throw an exception or it may succeed, at the option of the implementation. Such exceptions are marked as "optional" in the specification for this interface.
This interface is a member of the Java Collections Framework.
Many methods in Collections Framework interfaces are defined in terms of the equals method. For example, the specification for the contains(Object o) method says: "returns true if and only if this collection contains at least one element e such that (o==null ? e==null : o.equals(e))." This specification should not be construed to imply that invoking Collection.contains with a non-null argument o will cause o.equals(e) to be invoked for any element e. Implementations are free to implement optimizations whereby the equals invocation is avoided, for example, by first comparing the hash codes of the two elements. (The Object.hashCode() specification guarantees that two objects with unequal hash codes cannot be equal.) More generally, implementations of the various Collections Framework interfaces are free to take advantage of the specified behavior of underlying Object methods wherever the implementor deems it appropriate.
Bags 나 multisets (한쌍의 elements를 포함하는 정돈되지 않은 collection들) 은 collection 인터페이스를 직접적으로 implement 받아야한다.
범 용 Collection 구현 클래스 (통상, 서브 인터페이스를 개입시켜 간접적으로 Collection 를 구현한다)는 두가지의 규정된 생성자를 제공해야 한다. : 빈 콜렉션을 생성하는 void(인수 없음) 생성자와 그 인수와 elements가 같은 새로운 콜렉션을 만드는 단일 인수를 갖는 생성자. 사실상, 후자의 생성자, Single argument를 가진 생성자는 어떤 collection을 복사할 수 있어 implementation collection type이 요구하는 같은 콜렉션을 생성한다. 이 convetion은 영향을 주는 방법이 없다(인터페이스는 생성자를 포함할 수 없다.) 하지만 모든 collection implementation은 java platform libraries에 준거하고 있다.
destructive 메소드는 인터페이스내에 포함되어 있고, 그것은 수행하는 동안 collection을 수정한다. 수행하는 동안 collection이 제공되지 않는 경우에 Unsupported Operation Exception을 기술하여준다. 이런 경우에 그 메소드들은 주문이 collection에 아무 영향을 미치지 않을 경우에, (예를들어 addAll 메소드, 수정할 수 없는 콜렉션인 경우, 콜렉션이 비어있는 경우 exception을 throw 한다.) Unsupported Operation Exception을 기술하여준다.
어떤 Collection 구현들은 포함되어있는 요소들에 대한 제한들을 가지고 있다. 예를 들어, 어떤 구현들은 null 요소를 금지하고, 어떤 것들은 요소의 type에 제한을 가지고 있다. 적절하지 못한 요소들을 추가하려고 하면 검증되지 않은 exception을 발생시킨다, 보통은 NullPointerException 이나 ClassCastException. 적절하지 못한 요소의 존재를 물을려고 시도한다면 Exception을 줄 것이다, 또는 단순히 false를 반환할 것이다. 몇 구현들은 앞선 행동을 보여줄 것이다. 그리고 몇 구현들은 후의 행동들을 보여줄 것이다. 더 일반적으로, 콜렉션에 부적절한 요소의 삽입이 완성을 생기게하는 부적절한 요소의 수행을 시도하면 구현의 선택에 따라서 exception을 주거나 성공을 할 수도 있다. 이 인터페이스를 위해서 “Optional” 내용처럼 exception이 두드러진다
이 인터페이스는 Java Collections Framework의 구성원이다.
Java Collections Framework내부의 많은 메소드들은 equal 메소드의 사이에 정의 되어 있다. 예를 들어, contains(Object o) 메소드의 내용에서는:;;;
