#java #immutability #readonly-collection
#java #неизменяемость #коллекция только для чтения
Вопрос:
Я ищу библиотеку Java для коллекций без методов, допускающих мутации. эффективно неизменяемые коллекции только для чтения.
Под этим я подразумеваю ОТСУТСТВИЕ МЕТОДОВ. Не похоже на обычные неизменяемые коллекции Java, в которых есть такие методы, как add или remove , которые генерируют исключение при вызове. Нет… Я хочу, чтобы компилятор сообщал мне, что я пытаюсь сделать что-то недопустимое, вместо какой-либо ошибки во время выполнения.
Я знаю, что он существует, потому что я его использовал, но я не могу вспомнить название такой библиотеки.
Комментарии:
1.Напишите класс-оболочку! Но все, что вы используете, не будет a
Collection, поскольку всеCollections должны объявлять эти методы, потому что это часть интерфейса aCollection2. @xtratic Я знаю, что такая библиотека существует. Кроме того, моя компания не предоставит мне места для реализации указанных оболочек.
3. Обертки не помогут, так как это не приведет к ошибке во время компиляции.
4. @Horse если вы создаете оболочку, которая предоставляет только методы «чтения» .. тогда это, безусловно, приведет к ошибкам компиляции при попытке использовать методы «записи», которые не представлены / определены.
5. @AlejandroNavas Пожалуйста, будьте особенно осторожны при выборе платформы сбора данных, поскольку это будет иметь очень большое влияние, если ваши интерфейсы / модули будут использоваться компанией. Кроме того, с некоторыми несовместимыми версиями библиотек на протяжении многих лет существуют проекты, которые прибегали к затенению определенных версий. Опять же, не обескураживайте, но, пожалуйста, будьте особенно осторожны при выборе структуры сбора с коротким фокусом.
Ответ №1:
Коллекции Eclipse: https://www.eclipse.org/collections /
В их собственном руководстве по неизменяемым коллекциям говорится:
Все базовые контейнеры в коллекциях Eclipse имеют интерфейсы как для изменяемых, так и для неизменяемых (неизменяемых) форм. Это несколько отличается от модели JCF, в которой большинство контейнеров изменчивы.
Неизменяемая коллекция — это просто то, что после создания ее никогда нельзя изменить, сохраняя одни и те же внутренние ссылки и данные на протяжении всего срока службы. Неизменяемая коллекция равна соответствующей изменяемой коллекции с тем же содержимым; a
MutableListи anImmutableListмогут быть равны.
Комментарии:
1. ЭТИ! большое спасибо! Это то, что я искал. Я не знаю, почему я забыл название
2. Как вы хорошо обнаружили, у Guava
ImmutableCollectionесть методы мутации, которые выбрасывают. Я также посмотрел на Trove, hppc, fastutil, koloboke и Javolution, и ни один из них не предлагает то, что вы хотите.3. Спасибо @Petr! Все еще собираюсь проверить другие библиотеки
4. Все это говорит о том, что я сам в своем коде использую только неизменяемые коллекции Guava, поскольку они обеспечивают хороший баланс и совместимы со всем существующим кодом повсюду. Кроме того, их методы мутации показывают предупреждения при компиляции, что для нас достаточно хорошо. Коллекции Eclipse, хотя и очень хороши, требуют, чтобы вы использовали их и только их везде, где это возможно.
5. Я собираюсь использовать коллекции Eclipse, поскольку я пытаюсь, чтобы моя команда постепенно приобретала функциональный подход к программированию. Учитывая, что у них очень императивное мышление, я также не хочу, чтобы для этого во время выполнения создавались какие-то подлые исключения. К счастью, изменяемые коллекции eclipse реализуют иерархию коллекций Java, поэтому мне просто нужно добавить .toMutableList() или что-то в этом роде, чтобы он взаимодействовал с другими библиотеками
Ответ №2:
Неизменяемые коллекции Guava объявляют изменяемые методы с использованием @Deprecated , поэтому их использование выдаст предупреждение компилятора.
Это, вероятно, лучшее из обоих миров, поскольку оно позволяет передавать an ImmutableCollection везде Collection , где ожидается.
Комментарии:
1. Честно говоря, я предпочитаю создавать обычный список Java из неизменяемой коллекции Eclipse
2. @meriton,
ImmutableCollectionне гарантирует проверку времени компиляции, как ожидалось OP (даже продвинутый сканер кода не может переносить глубоко вложенные реализации, абстрагирующие фактический созданный объект). Это явно требует компромисса между совместимостью интерфейса с javaCollectionилиcompile time check.