상세 컨텐츠

본문 제목

Collection 클래스

Programming/Java

by 노란날. 2013. 10. 1. 01:22

본문

반응형

java.util 
인터페이스 Collection<E>

모든 슈퍼 인터페이스:
Iterable <E>
기존의 서브 인터페이스의 일람:
BeanContext , BeanContextServices , BlockingDeque <E>, BlockingQueue <E>, Deque <E>, List <E>, NavigableSet <E>, Queue<E>, Set <E>, SortedSet <E>
기존의 구현 클래스의 일람:
AbstractCollection , AbstractList , AbstractQueue , AbstractSequentialList , AbstractSet , ArrayBlockingQueue , ArrayDeque ,ArrayList , AttributeList , BeanContextServicesSupport , BeanContextSupport , ConcurrentLinkedQueue , ConcurrentSkipListSet ,CopyOnWriteArrayList , CopyOnWriteArraySet , DelayQueue , EnumSet , HashSet , JobStateReasons , LinkedBlockingDeque ,LinkedBlockingQueue , LinkedHashSet , LinkedList , PriorityBlockingQueue , PriorityQueue , RoleList , RoleUnresolvedList , Stack ,SynchronousQueue , TreeSet , Vector


public interface Collection<E>
extends Iterable <E>

「컬렉션 계층」 루트 인터페이스입니다. 컬렉션은, 그 「요소」인 객체의 그룹을 나타냅니다. 컬렉션에 따라서는 요소의 중복을 허가합니다만, 허가하지 않는 컬렉션도 있습니다. 

또, 순서 붙일 수 있고 있는 컬렉션과 그렇지 않은 컬렉션이 있습니다. JDK 는, 

이 인터페이스의 「직접」의 구현을 일절 제공하지 않습니다. Set 및 List 와 같은, 

보다 용도의 특정된 서브 인터페이스를 제공합니다. 

이 인터페이스는, 일반적으로은, 최대한의 보편성이 요구되는 장면에서 컬렉션을 건네주거나 그 컬렉션을 조작하기 위해서 사용됩니다.

「Bag」또는 「멀티 세트」(중복 요소를 포함할 수 있는, 순서 붙이고가 없는 컬렉션)은, 이 인터페이스를 직접 구현할 필요가 있습니다.

범용 Collection 구현 클래스 (일반적으로, 서브 인터페이스를 개입시켜 간접적으로 Collection 를 구현한다)는, 2 개(살)의 「표준」생성자 을 제공하지 않으면 안됩니다. 빈 상태(empty)의 컬렉션을 작성하는 void (인수 없음) 생성자 과Collection 형의 인수를 1 개 가져, 그 인수와 같은 요소로 새로운 컬렉션을 작성하는 생성자 입니다. 따라서, 후자의 생성자 에서는, 사용자는 어느 컬렉션에서도 카피할 수 있어 희망의 구현형의 컬렉션과 완전하게 같은 컬렉션을 생성할 수 있습니다. 이 규약은 의무 지워지고 있는 것은 아닙니다만 (인터페이스는 생성자 을 포함할 수 없기 때문에), Java 플랫폼 라이브러리에 있어서의 모든 범용 Collection 의 구현은 이 규약에 준거하고 있습니다.

이 컬렉션이 오퍼레이션을 지원하고 있지 않는 경우, 이 인터페이스 (처리되는 컬렉션을 수정하는 메소드)에 포함되어 있는 「파괴적인」메소드는,UnsupportedOperationException 를 throw 하도록(듯이) 지정되고 있습니다. 이 때, 호출이 컬렉션에 영향을 주지 않는 경우, 이러한 메소드는,UnsupportedOperationException 를 throw 할 수가 있습니다만, 필수가 아닙니다. 예를 들어, 추가된 컬렉션이 빈 상태(empty)인 경우, 변경 불가능한 컬렉션으로 addAll(Collection) 를 호출하면(자), 예외를 throw 할 수가 있습니다만, 필수가 아닙니다.

컬렉션의 구현에는, 포함할 수 있는 요소에 제한이 있는 것도 있습니다. 예를 들어, null 요소를 금지하는 구현이나, null 요소의 형태에 제한이 있는 구현도 있습니다. 부적당한 요소를 추가하려고 하면(자), 일반적으로 NullPointerException 또는 ClassCastException 와 같은 체크되지 않는 예외가 throw 됩니다. 부적당한 요소를 조회하려고 하면(자), 예외가 throw 되는 경우나, 다만 false 를 돌려주는 경우도 있습니다. 전의 동작을 금지하는 구현도 있으면, 후의 동작을 금지하는 구현도 있습니다. 전의 동작을 표시하는 구현도 있으면, 나머지의 동작을 표시하는 구현도 있습니다. 많은 경우는, 컬렉션에의 삽입이 되지 않는 부적격인 요소를 처리하려고 하면(자), 구현에 의해 예외가 throw 되거나 처리가 유효하게 됩니다. 이 인터페이스에 관한 그러한 예외는, 「임의」의 스펙으로서 마크 됩니다.

독자적인 동기 정책를 결정할지 어떨지는, 각각의 컬렉션에 따라서 다릅니다. 구현에 의한 강한 보증이 없는 경우, 다른 thread에 의해 변경되는 컬렉션으로 메소드를 호출하면(자), 정의되어 있지 않은 동작이 발생할 가능성이 있습니다. 이것에는, 직접적인 호출해, 호출을 실행할 가능성이 있는 메소드에의 컬렉션의 인도해, 및 기존의 반복자를 사용한 컬렉션의 검사가 포함됩니다.

Collections Framework 인터페이스내의 다수의 메소드는,equals 메소드와의 관련으로 정의됩니다. 예를 들어,contains(Object o) 메소드의 스펙은, 「이 컬렉션에 (o==null ? e==null :o.equals(e)) 를 채우는 요소 e 가 1 개 이상 포함되는 경우에게만,true 를 돌려준다」라고 하는 것입니다. 이 스펙은, 「null 이외의 인수 o 를 사용해 Collection.contains 를 호출하면(자), 요소 e 로 o.equals(e) 가 불려 간다」라고 이해해야 하지는 않습니다. 최적화의 구현 방법은 자유롭기 때문에, 2 개의 요소의 해시 코드를 비교하는 등 방법으로 equals 의 호출은 피할 수 있는 (Object.hashCode() 스펙에서는, 등가가 아닌 해시 코드를 보관 유지하는 2 개의 객체는 등가가 아닌 것이 보증된다). 일반적으로, 다양한 Collections Framework 인터페이스의 구현으로, 구현자가 적절이라고 판단한다면, 기반이 되는 Object 메소드의 지정된 동작을 자유롭게 이용할 수 있습니다.

이 인터페이스는,Java Collections Framework 의 멤버입니다.





반응형

관련글 더보기