Интерфейс 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 немодифицируем, List, возвращаемый методом 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.