Реализации обертки

Реализации обертки делегируют всю свою реальную работу к указанному набору, но добавляют дополнительную функциональность сверху того, что предлагает этот набор. Для вентиляторов шаблона разработки это - пример шаблона "декоратор". Хотя это может казаться немного экзотичным, это действительно довольно прямо.

Эти реализации являются анонимными; вместо того, чтобы обеспечивать общедоступный class, библиотека обеспечивает статический метод фабрики. Все эти реализации находятся в Collections class, который состоит исключительно из статических методов.

Обертки синхронизации

Обертки синхронизации добавляют автоматическую синхронизацию (потокобезопасность) к произвольному набору. Каждый из шести базовых интерфейсов набора — Collection, Set, List, Map, SortedSet, и SortedMap — имеет один статический метод фабрики.

public static <T> Collection<T> synchronizedCollection(Collection<T> c);
public static <T> Set<T> synchronizedSet(Set<T> s);
public static <T> List<T> synchronizedList(List<T> list);
public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m);
public static <T> SortedSet<T> synchronizedSortedSet(SortedSet<T> s);
public static <K,V> SortedMap<K,V> synchronizedSortedMap(SortedMap<K,V> m);

Каждый из этих методов возвращает (ориентированный на многопотоковое исполнение) синхронизируемый Collection поддержанный указанным набором. Чтобы гарантировать последовательный доступ, весь доступ к отступающему набору должен быть выполнен через возвращенный набор. Легкий способ гарантировать это не состоит в том, чтобы сохранить ссылку на отступающий набор. Создайте синхронизируемый набор со следующим приемом.

List<Type> list = Collections.synchronizedList(new ArrayList<Type>());

Набор, создаваемый этим способом, является каждым битом столь же ориентированным на многопотоковое исполнение как обычно синхронизируемый набор, такой как a Vector.

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

Collection<Type> c = Collections.synchronizedCollection(myCollection);
synchronized(c) {
    for (Type e : c)
        foo(e);
}

Если явный iterator используется, iterator метод нужно вызвать изнутри synchronized блок. Отказ последовать этому совету может привести к недетерминированному поведению. Идиома для того, чтобы выполнить итерации по a Collection представление синхронизируемого Map подобно. Обязательно, чтобы пользователь синхронизировался на синхронизируемом Map выполняя итерации по любому из Collection представления вместо того, чтобы синхронизироваться на Collection представление непосредственно, как показано в следующем примере.

Map<KeyType, ValType> m = Collections.synchronizedMap(new HashMap<KeyType, ValType>());
    ...
Set<KeyType> s = m.keySet();
    ...
// Synchronizing on m, not s!
synchronized(m) {
    while (KeyType k : s)
        foo(k);
}

Одна незначительная нижняя сторона использования реализаций обертки - то, что у Вас нет возможности выполнить любые операции неинтерфейса обернутой реализации. Так, например, в предыдущем List пример, невозможно вызвать ArrayList's ensureCapacity работа на обернутом ArrayList.

Неподдающиеся изменению Обертки

В отличие от оберток синхронизации, которые добавляют функциональность к обернутому набору, неподдающиеся изменению обертки убирают функциональность. В частности они убирают возможность изменить набор, прерывая все операции, которые изменили бы набор и бросок UnsupportedOperationException. У неподдающихся изменению оберток есть два основного использования, следующим образом:

• Сделать набор неизменным, как только это было создано. В этом случае это - хорошая практика, чтобы не поддержать ссылку на отступающий набор. Это абсолютно гарантирует неизменность.
• Позволить определенный клиентский доступ только для чтения к Вашим структурам данных. Вы сохраняете ссылку на отступающий набор, но раздаете ссылку на обертку. Таким образом клиенты могут смотреть, но не изменить, в то время как Вы поддерживаете полный доступ.

Как обертки синхронизации, каждое из шести ядер Collection у интерфейсов есть один статический метод фабрики.

public static <T> Collection<T> unmodifiableCollection(Collection<? extends T> c);
public static <T> Set<T> unmodifiableSet(Set<? extends T> s);
public static <T> List<T> unmodifiableList(List<? extends T> list);
public static <K,V> Map<K, V> unmodifiableMap(Map<? extends K, ? extends V> m);
public static <T> SortedSet<T> unmodifiableSortedSet(SortedSet<? extends T> s);
public static <K,V> SortedMap<K, V> unmodifiableSortedMap(SortedMap<K, ? extends V> m);

Проверенные Обертки Интерфейса

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