Обновление класса Collections

Если Вы посмотрите на приведенный перечень классов коллекций, то увидите, что у класса Сollections нет параметра типа. Причина заключается в том, что класс Сollections целиком состоит из статических методов, которые реализуют алгоритмы обработки коллекций. Следовательно, нет смысла делать этот класс настраиваемым. Однако его методы модифицированы для применения настраиваемых типов благодаря передаче в метод и возврату из метода настраиваемых типов.

В класс collections также включено несколько новых методов. Возможно самый важный среди них набор перегруженных методов checked, таких как checkedСollection(), который возвращает представление коллекции, названное в документации "представлением времени выполнения, обеспечивающим типовую безопасность". Это означает ссылку на коллекцию, в которой динамически во время выполнения проверяется типовое соответствие каждого включаемого в нее элемента. Попытка вставить в коллекцию несовместимый элемент вызывает генерацию исключения типа ClassCastException. Применение такого представления коллекции очень полезно во время отладки, потому что гарантирует наличие в коллекции только подходящих элементов. К родственным методам относятся также методы: CheckedSet(), CheckedList(), CheckedMap() и т.д. Они возвращают представление, наделенное типовой безопасностью, для указанной коллекции.

Кроме того, в класс Collections включены следующие новые методы:

• метод frequency (), возвращающий число вхождений элемента;

• метод disjoint (), возвращающий значение true, если у двух коллекций нет общих элементов;

• метод addAll(), вставляющий содержимое массива в коллекцию;

• метод reverseOrder(), возвращающий объект типа comparator для обратного порядка следования элементов.

Почему настраиваемые коллекции

Подробное обсуждение преимуществ использования настраиваемых типов применительно к коллекциям можно найти в главе 3. Здесь же приведено краткое резюме.

В прошлом в коллекции содержались ссылки на объекты класса Object, которые могли указывать на объекты любого типа. Теперь Вы явно задаете тип данных, хранящийся в коллекции. Например, вызов:

list.add("Collections");

корректен, т. к. строка в кавычках — это тип String. Приведенный далее оператор содержит ошибку, поскольку делается попытка сохранить объект класса Integer в переменной list:

list.add(new Integer(10) ); // Ошибка

Этот вызов порождает ошибку несовместимости типов, потому что класс Integer несовместим с типом String.

Еще одно преимущество применения настраиваемых типов в коллекциях заключается в том, что становится ненужным приведение типов при извлечении элемента из коллекции. В исходном тексте старого стиля для получения строки из коллекции list пришлось бы написать оператор, подобный следующему:

String str = (String) list.get(0); //код старого стиля

Раньше приведение типов было необходимо, так как вызов list.get () возвращал тип Object, а не String. Теперь, с появлением настраиваемых типов, Вы можете написать следующий оператор:

String str = list.get(0); // код нового стиля, автоматически извлекается

// тип String

поскольку переменная list — типа LinkedList<String>, компилятору автоматически становится известно о том, что у ссылки, возвращаемой методом list.get(), тип String, и никакого явного приведения типов не требуется.

Помимо удобства, устранение явных преобразований типов также препятствует появлению ошибок. Невозможно случайно преобразовать ссылку, возвращенную методом, таким как get (), в несовместимый тип. В прошлом такие некорректные приведения типов порождали ошибки времени выполнения. С появлением настраиваемых типов подобные недопустимые преобразования типов обнаруживаются на этапе компиляции и могут быть устранены до того, как код будет введен в эксплуатацию.