Почему Collections.checkedMap и друзья не используются чаще? - PullRequest
9 голосов
/ 12 января 2011

Недавно я наткнулся на Javadoc для семейства функций Collection.checkedMap для создания динамически безопасных типов стандартных типов коллекций.Учитывая, что они добавляют еще один уровень безопасности поверх коллекций, который диагностирует относительно распространенную ошибку программиста, я бы подумал, что они будут более популярными.По какой-то причине, однако, во всех крупных Java-проектах, над которыми я работал, я не видел, чтобы они использовались один раз.

Мой вопрос таков: есть ли конкретная причина, по которой Java-программисты неиспользовать эти проверенные обертки чаще?Или это просто отсутствие выгоды / отсутствие знаний об их существовании?

РЕДАКТИРОВАТЬ : Чтобы прояснить мой вопрос, универсальные версии коллекций по-прежнему содержат небезопасные функции.Например, Map containsKey, containsValue, remove и get работают на Object.Мой главный вопрос, учитывая эту небезопасность типов, почему все больше людей не используют проверенные реализации для диагностики нарушений типов во время выполнения.

Ответы [ 2 ]

15 голосов
/ 12 января 2011

Эти классы действительно необходимы, только если кто-то использует (или не использует) дженерики.Он дублирует проверки во время выполнения, которые должны быть достаточными для выполнения во время компиляции через гарантии безопасности типов механизмом обобщений.

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

Вот в чем суть: если ваш код компилируется без необработанных предупреждений типа или каких-либо непроверенныхпредупреждения о конверсиях / типах: гарантировано , что методы checked* не дают вам никакой выгоды;они являются только хитом во время выполнения.

Редактировать

Похоже, вы пришли к выводу, что, поскольку remove, get и т. д. работают на Object, оникак-то небезопасно.Они не.Ни один из этих методов не сохранит свой операнд на карте, так что вы определенно не ставите под угрозу безопасность типов самой карты.Эти методы принимают объект по одной основной причине: для обратной совместимости.Никогда не было каких-либо строгих требований, чтобы при поиске нужно было придерживаться одного и того же класса.Например, если экземпляр класса A и экземпляр класса B могут как-то быть равны друг другу, поместите a в карту и затем вызовите remove(b) , следует удалить отображение a.

Это поведение необходимо было поддерживать после добавления обобщений для сохранения обратной совместимости.Таким образом, они не могли обновить интерфейс до чего-то вроде remove(K), так как существующий код может полагаться на возможность удалить отображение, учитывая экземпляр совершенно другого класса.Однако он не является небезопасным, и использование проверенной версии карты не меняет этого поведения ни в малейшей степени.

0 голосов
/ 12 января 2011

ОТКЛЮЧЕНИЕ: следующее мнение неверно. Помимо обратной совместимости, есть несколько веских причин, по которым лучше иметь индекс поиска любого типа.

Нет божественной причины, почему эти методы должны принимать Object вместо E. В реальных программах, если передается объект не-E, это почти наверняка ошибка приложения. API версии E в большинстве ситуаций будет лучше, чем версия Object. И я говорю, что Сун допустил ошибку здесь. Нет проблем с обратной совместимостью, потому что универсальный API - это совершенно новый API.

К счастью, моя IDE (IntelliJ) предупредит меня, если я передам не-E тип этим методам. Статическая проверка была расширена за пределы того, что говорит языковая спецификация и что делает компилятор.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...