Интерфейс Collection<E>

public interface Collection<E> extends Iterable<E>

Основной интерфейс в иерархии коллекций. Коллекция представляет собой группу объектов, известных как её элементы. Некоторые коллекции допускают дублирование элементов, а другие — нет. Некоторые упорядочены, а другие — нет. Коллекции, у которых определён порядок элементов, обычно являются подтипами интерфейса SequencedCollection. JDK не предоставляет непосредственных реализаций этого интерфейса: он предоставляет реализации более конкретных подинтерфейсов, таких как Set и List. Этот интерфейс обычно используется для передачи и манипулирования коллекциями, где требуется максимальная общность.

Множества или мультимножества (неупорядоченные коллекции, которые могут содержать дублирующиеся элементы) должны реализовывать этот интерфейс непосредственно.

Все общие реализации Collection (которые обычно реализуют Collection косвенно через один из его подинтерфейсов) должны предоставлять два «стандартных» конструктора: конструктор без аргументов, который создаёт пустую коллекцию, и конструктор с одним аргументом типа Collection, который создаёт новую коллекцию с теми же элементами, что и её аргумент. По сути, последний конструктор позволяет пользователю копировать любую коллекцию, создавая эквивалентную коллекцию нужного типа реализации. Нет способа принудительно следовать этой конвенции (так как интерфейсы не могут содержать конструкторы), но все общие реализации Collection в библиотеках Java платформы соответствуют ей.

Некоторые методы определены как необязательные. Если реализация коллекции не реализует определённую операцию, она должна определить соответствующий метод, чтобы тот бросал исключение UnsupportedOperationException. Такие методы в спецификациях методов интерфейсов коллекций помечены как «необязательная операция».

Некоторые реализации коллекций имеют ограничения на элементы, которые они могут содержать. Например, некоторые реализации запрещают null-элементы, а некоторые имеют ограничения на типы элементов. Попытка добавить неподходящий элемент вызывает необработанное исключение, обычно NullPointerException или ClassCastException. Попытка запросить наличие неподходящего элемента может вызвать исключение или просто вернуть false; некоторые реализации будут демонстрировать первое поведение, а некоторые — второе. Более обобщённо, попытка операции с неподходящим элементом, выполнение которой не приведёт к вставке неподходящего элемента в коллекцию, может вызвать исключение или завершиться успешно, по выбору реализации. Такие исключения помечены как «необязательные» в спецификации для этого интерфейса.

Каждая коллекция сама определяет свою политику синхронизации. При отсутствии более сильного гарантии от реализации, вызов любого метода на коллекции, которая изменяется другим потоком, может привести к неопределённому поведению; это включает прямые вызовы, передачу коллекции методу, который может выполнить вызовы, и использование существующего итератора для просмотра коллекции.

Многие методы в интерфейсах Collections Framework определены с точки зрения метода equals. Например, спецификация метода contains(Object o) гласит: «возвращает true тогда и только тогда, когда эта коллекция содержит по крайней мере один элемент e такой, что (o==null ? e==null : o.equals(e))». Эта спецификация не должна интерпретироваться как импликация, что вызов Collection.contains с ненулевым аргументом o вызовет o.equals(e) для любого элемента e. Реализации могут свободно использовать оптимизации, в которых вызов equals избегается, например, сравнивая сначала хеш-коды двух элементов. (Спецификация Object.hashCode() гарантирует, что два объекта с неравными хеш-кодами не могут быть равны.) Более обобщённо, реализации различных интерфейсов Collections Framework свободно могут воспользоваться указанным поведением базовых методов Object там, где реализатор считает это уместным.

Некоторые операции с коллекциями, которые выполняют рекурсивную обработку коллекции, могут завершиться исключением для самоссылочных экземпляров, где коллекция непосредственно или косвенно содержит себя. Это включает методы clone(), equals(), hashCode() и toString(). Реализации могут по желанию обрабатывать самоссылочный сценарий, однако большинство текущих реализаций этого не делают.

Коллекции-представления

Большинство коллекций управляют хранилищем элементов, которые они содержат. В отличие от этого, коллекции-представления сами не хранят элементы, а вместо этого опираются на базовую коллекцию для хранения фактических элементов. Операции, которые не обрабатываются коллекцией-представлением, делегируются базовой коллекции. Примеры коллекций-представлений включают обертки коллекций, возвращаемые методами, такими как Collections.checkedCollection, Collections.synchronizedCollection и Collections.unmodifiableCollection. Другие примеры коллекций-представлений включают коллекции, которые предоставляют другое представление тех же элементов, например, как предоставляется методами List.subList, NavigableSet.subSet, Map.entrySet или SequencedCollection.reversed. Любые изменения, внесённые в базовую коллекцию, видны в коллекции-представлении. Соответственно, любые изменения, внесённые в коллекцию-представление (если изменения разрешены), записываются в базовую коллекцию. Хотя они технически не являются коллекциями, экземпляры Iterator и ListIterator также могут позволить запись изменений в базовую коллекцию, и в некоторых случаях изменения в базовой коллекции будут видны итератору во время итерации.

Неизменяемые коллекции

Некоторые методы этого интерфейса считаются «разрушающими» и называются «методами-мутаторами», так как они изменяют группу объектов, содержащихся в коллекции, над которой они работают. Они могут быть определены так, чтобы бросать UnsupportedOperationException, если реализация этой коллекции не поддерживает операцию. Такие методы должны (но не обязаны) бросать UnsupportedOperationException, если вызов не окажет никакого влияния на коллекцию. Например, рассмотрим коллекцию, которая не поддерживает операцию add. Что произойдёт, если метод addAll будет вызван для этой коллекции с пустой коллекцией в качестве аргумента? Добавление нуля элементов не оказывает влияния, поэтому разрешено, чтобы эта коллекция просто ничего не делала и не выбрасывала исключение. Тем не менее, рекомендуется, чтобы в таких случаях исключение выбрасывалось безоговорочно, так как выбрасывание только в определённых случаях может привести к ошибкам программирования.

Неизменяемая коллекция — это коллекция, все методы-мутаторы которой (как определено выше) определены так, чтобы бросать UnsupportedOperationException. Таким образом, такая коллекция не может быть изменена путём вызова методов на ней. Для того, чтобы коллекция была должным образом неизменяемой, все коллекции-представления, производные от неё, также должны быть неизменяемыми. Например, если список неизменяем, список, возвращаемый List.subList, также неизменяем.

Неизменяемая коллекция не обязательно является неизменяемой в строгом смысле. Если содержащиеся элементы изменяемы, вся коллекция явно изменяема, даже если она может быть неизменяемой. Например, рассмотрим два неизменяемых списка, содержащих изменяемые элементы. Результат вызова list1.equals(list2) может отличаться от одного вызова к другому, если элементы были изменены, даже если оба списка неизменяемы. Однако, если неизменяемая коллекция содержит только неизменяемые элементы, она может считаться эффективно неизменяемой.

Неизменяемые коллекции-представления

Неизменяемая коллекция-представление — это коллекция, которая неизменяема и также является представлением базовой коллекции. Её методы-мутаторы бросают UnsupportedOperationException, как описано выше, в то время как методы чтения и запроса делегируются базовой коллекции. Это позволяет обеспечить только чтение базовой коллекции. Это полезно, если компоненту нужно предоставить пользователям доступ для чтения к внутренней коллекции, одновременно предотвращая неожиданное изменение таких коллекций. Примеры неизменяемых коллекций-представлений — это те, которые возвращаются методами Collections.unmodifiableCollection, Collections.unmodifiableList и подобными.

Обратите внимание, что изменения в базовой коллекции всё ещё возможны, и если они произойдут, они будут видны через неизменяемое представление. Таким образом, неизменяемая коллекция-представление не обязательно является неизменяемой в строгом смысле. Однако, если базовая коллекция неизменяемой коллекции-представления фактически неизменяема, или если единственная ссылка на базовую коллекцию — через неизменяемое представление, то представление можно считать фактически неизменяемым.

Сериализация коллекций

Сериализация коллекций — необязательна. Поэтому ни один из интерфейсов коллекций не объявлен реализующим интерфейс Serializable. Однако, сериализация считается полезной, поэтому большинство реализаций коллекций сериализуемы.

Реализации коллекций, которые являются общедоступными классами (такими как ArrayList или HashMap), объявлены реализующими интерфейс Serializable, если они действительно сериализуемы. Некоторые реализации коллекций не являются общедоступными классами, например, неизменяемые коллекции. В таких случаях сериализация таких коллекций описывается в спецификации метода, который их создаёт, или в другом подходящем месте. В случаях, когда сериализация коллекции не указана, нет гарантий о сериализации таких коллекций. В частности, многие коллекции-представления не сериализуемы, даже если исходная коллекция сериализуема.

Реализация коллекции, которая реализует интерфейс Serializable, не гарантируется как сериализуемая. Причина в том, что в общем случае коллекции содержат элементы других типов, и статически невозможно определить, являются ли экземпляры какого-либо типа элементов фактически сериализуемыми. Например, рассмотрим сериализуемую Collection<E>, где E не реализует интерфейс Serializable. Коллекция может быть сериализуемой, если она содержит только элементы некоторого сериализуемого подтипа E или если она пуста. Следовательно, коллекции называются условно сериализуемыми, так как сериализуемость коллекции в целом зависит от того, является ли сама коллекция сериализуемой и от того, являются ли все содержащиеся элементы также сериализуемыми.

Дополнительный случай возникает с экземплярами SortedSet и SortedMap. Эти коллекции можно создать с помощью Comparator, который задаёт порядок элементов множества или ключей отображения. Такая коллекция сериализуема только в том случае, если предоставленный Comparator также сериализуем.

Этот интерфейс является членом Java Collections Framework.