Java: Делает ли Collections.unmodifiableXYZ (...) в особых случаях объект коллекции в наименьший вес?

Question

Возможные ответы: "никогда" или "это зависит" .

Лично я бы сказал, это зависит .

Следующее использование сделало бы коллекцию похожей (на мой взгляд) на вес:

public final static List<Integer> SOME_LIST = 
  Collections.unmodifiableList(
    new LinkedList<Integer>(){ // scope begins
      {
        add(1);
        add(2);
        add(3);
      }
    } // scope ends
  );

Правильно? Вы не можете когда-либо изменить его, потому что единственное место, где «оригинальный» объект коллекции известен (который может быть изменен), является область видимости внутри unmodifiableList списка параметров, который заканчивается немедленно.

Второе: когда вы извлекаете элемент из списка, это Целое число , которое само по себе является наименьшим весом.

Другие очевидные случаи, когда final static и unmodifiableList являются не используется, не будет считаться маховиком.

Я что-то пропустил?
Должен ли я учитывать некоторые внутренние аспекты LinkedList , которые могли бы скомпрометировать вес?

Answer 1

Я думаю, что вы имеете в виду шаблон flyweight. Фундаментальная идея этого шаблона заключается в том, что вы имеете дело со сложными объектами, экземпляры которых можно использовать повторно, и выдает различные представления их методами.

для правильной работы такого объекта он должен быть неизменным.

неизменность четко указывается при создании списка, как вы описали. но поскольку нет внешнего объекта / параметров, с которыми работает SOME_LISt, я бы не назвал это примером шаблона с наименьшим весом.

Другим типичным свойством шаблона flyweight является «интернирование» таких объектов. при создании только одного экземпляра объекта это не имеет смысла.

, если вы много работаете со списками, которые передаются от одного объекта к другому, и вы хотите обеспечить неизменность, лучшим вариантом может быть использование Google-Collections .

final static ImmutableList<Integer> someList = ImmutableList.of(1, 2, 3);

Конечно, также возможно создавать более сложные неизменные объекты с помощью Builders.

это создает экземпляр неизменяемого списка. он по-прежнему будет реализовывать интерфейс List, но откажется выполнять любые операции add (), addAll () set (), remove ().

так что вы все равно можете передавать его методам, когда требуется интерфейс List, но при этом быть уверенным, что его содержимое не изменяется.

Answer 2

Наличие библиотеки, обнаружившей, что изменчивый List не избежал иного, является чем-то вроде запроса, хотя теоретически возможно.

Если вы сериализуете возвращенный объект, то доверенный код сможет просмотреть внутренний объект. Хотя сериализованная форма класса задокументирована, не задокументировано, что метод использует эти классы.

В практическом плане любой кеш зависит от пользователя API.

(Почему LinkedList для неизменяемого списка, кстати? Кроме того, это изменяет неизменяемую реализацию.)

Answer 3

Я думаю, что ваш пример для неизменных объектов, мухи - это нечто совсем другое. Неизменяемые объекты являются кандидатами на вес в полете, но вес в полете не обязательно должен быть неизменным, он просто должен быть спроектирован для экономии памяти.

Answer 4

Целое число - только наименьший вес от -128 до 127.

См. Также http://www.javaworld.com/javaworld/jw-07-2003/jw-0725-designpatterns.html.