Які причини того, що Map.get (ключ об’єкта) не є (повністю) загальним

Які причини обумовлені рішенням не мати повністю загального методу отримання в інтерфейсі java.util.Map<K, V>.

Для уточнення питання підпис методу є

V get(Object key)

замість

V get(K key)

і мені цікаво чому (те саме для remove, containsKey, containsValue).

Як зазначають інші, причина, чому get()тощо, не є загальною, оскільки ключ запису, який ви шукаєте, не повинен бути того ж типу, що і об'єкт, до якого ви переходите get(); специфікація методу вимагає лише рівності. Це випливає з того, як equals()метод приймає в об'єкті параметр, а не просто той самий тип, що і об'єкт.

Хоча може бути правдою, що багато класів equals()визначили так, що його об'єкти можуть бути рівними лише об'єктам власного класу, на Яві є багато місць, де це не так. Наприклад, специфікація List.equals()говорить про те, що два об'єкти List рівні, якщо вони обидва Списки і мають однаковий вміст, навіть якщо вони різні реалізації List. Так що, повертаючись до прикладу в цьому питанні, в відповідності зі специфікацією методи можна мати Map<ArrayList, Something>і для мене , щоб зателефонувати get()з в LinkedListякості аргументу, і він повинен отримати ключ , який представляє собою список з тим же вмістом. Це було б неможливо, якби get()були загальні та обмежили його тип аргументу.

Дивовижний кодер Java в Google, Кевін Боррліон, писав про це саме питання в публікації в блозі деякий час тому (правда, в контексті Setзамість цього Map). Найбільш відповідне речення:

Однозначно, методи рамки колекцій Java (і бібліотека колекцій Google також) ніколи не обмежують типи їх параметрів, за винятком випадків, коли це потрібно для запобігання розбиття колекції.

Я не зовсім впевнений, що згоден з цим як із принципом - .NET, здається, добре вимагає, наприклад, потрібного типу ключа, - але варто дотримуватися міркувань у публікації блогу. (Згадавши .NET, варто пояснити, що частина причини, чому це не проблема в .NET, полягає в тому, що більша проблема в .NET з більш обмеженою дисперсією ...)

Договір виражається так:

Більш формально, якщо ця карта містить відображення від ключа k до значення v таким, що (key == null? K == null: key.equals (k) ), тоді цей метод повертає v; в іншому випадку він повертається до нуля. (Таке відображення може бути максимум одним.)

(мій акцент)

і як такий, успішний пошук ключа залежить від реалізації методом рівності вхідного ключа. Це не обов'язково залежить від класу k.

Це застосування Закону Постеля, "будьте консервативні в тому, що ви робите, будьте ліберальні в тому, що приймаєте від інших".

Перевірки рівності можуть проводитися незалежно від типу; equalsметод визначений на Objectкласі і приймає будь-які в Objectякості параметра. Отже, є сенс для ключової еквівалентності та операцій, заснованих на еквівалентності ключів, приймати будь-який Objectтип.

Коли карта повертає ключові значення, вона зберігає стільки інформації типу, скільки може, використовуючи параметр типу.

Я думаю, що цей розділ Підручника з генерики пояснює ситуацію (мій акцент):

"Вам потрібно переконатися, що загальний API не є надмірно обмежувальним; він повинен продовжувати підтримувати оригінальний контракт API. Розгляньте ще кілька прикладів з java.util.Collection.

interface Collection { 
  public boolean containsAll(Collection c);
  ...
}

Наївна спроба узагальнити це:

interface Collection<E> { 
  public boolean containsAll(Collection<E> c);
  ...
}

Хоча це, безумовно, безпечно для типу, воно не відповідає оригінальному контракту API. Метод containsAll () працює з будь-яким типом вхідної колекції. Це вдасться лише в тому випадку, якщо вхідна колекція дійсно містить лише екземпляри E, але:

• Статичний тип вхідної колекції може відрізнятися, можливо, тому, що абонент не знає точного типу переданої колекції, або, можливо, тому, що це колекція <S>, де S є підтипом E.
• Цілком легітимним є дзвінок містить Content (All) () зі збіркою іншого типу. Рутина повинна працювати, повертаючи помилкове ".

Причина полягає в тому, що захисна оболонка визначається equalsі hashCodeякі є методи Objectі обидва приймають Objectпараметр. Це було недоліком дизайну в стандартних бібліотеках Java. У поєднанні з обмеженнями в системі типів Java вона змушує приймати все, що покладається на рівні і hashCode Object.

Єдиний спосіб мати тип безпечних хеш - таблиці і рівність в Java є цуратися Object.equalsі Object.hashCodeі використовувати загальний замінник. Функціональна Java поставляється з класами типів саме для цієї мети: Hash<A>і Equal<A>. Передбачена обгортка для HashMap<K, V>, яка приймає Hash<K>і Equal<K>в її конструктор. Отже, цей клас getта containsметоди приймають загальний аргумент типу K.

Приклад:

HashMap<String, Integer> h =
  new HashMap<String, Integer>(Equal.stringEqual, Hash.stringHash);

h.add("one", 1);

h.get("one"); // All good

h.get(Integer.valueOf(1)); // Compiler error

Сумісність.

Перш ніж були доступні дженерики, було просто отримати (Object o).

Якби вони змінили цей метод, щоб отримати (<K> o), це може призвести до примусового масового обслуговування коду для користувачів Java, щоб знову скомпілювати робочий код.

Вони могли б запровадити додатковий метод, скажімо get_ kontrole (<K> o) та зневірити старий метод get (), щоб з'явився шлях переходу ніжнішого. Але чомусь цього не було зроблено. (Зараз у нас ситуація полягає в тому, що вам потрібно встановити такі інструменти, як findBugs, щоб перевірити сумісність типу між аргументом get () та оголошеним типом ключа <K> карти.)

Аргументи, що стосуються семантики .equals (), я думаю. (Технічно вони правильні, але я все ще думаю, що вони хибні. Жоден дизайнер, що його розуму, не збирається робити o1.equals (o2) справжнім, якщо o1 і o2 не мають загального суперкласу.)

Є ще одна вагома причина - це неможливо зробити технічно, тому що він порушує Карту.

У Java є поліморфна родова побудова на кшталт <? extends SomeClass>. Позначена така посилання може вказувати на тип, підписаний <AnySubclassOfSomeClass>. Але поліморфний Generic робить , що посилання тільки для читання . Компілятор дозволяє використовувати загальні типи лише як метод повернення (наприклад, прості getters), але блокує використання методів, де generic type є аргументом (як звичайні задачі). Це означає, що якщо ви пишете Map<? extends KeyType, ValueType>, компілятор не дозволяє вам викликати метод get(<? extends KeyType>), і карта буде марною. Єдине рішення , щоб зробити цей метод не є універсальним: get(Object).

Зрозуміло, зворотна сумісність. Map(або HashMap) все ще потребує підтримки get(Object).

Я дивився на це і думав, чому вони так робили. Я не думаю, що жоден із існуючих відповідей не пояснює, чому вони не могли просто змусити новий загальний інтерфейс прийняти лише відповідний тип ключа. Фактична причина полягає в тому, що, хоча вони представили дженерики, вони НЕ створили новий інтерфейс. Інтерфейс Map - це та сама стара негенерична карта, вона просто слугує як загальною, так і загальною версією. Таким чином, якщо у вас є метод, який приймає не загальну карту, ви можете передати її, Map<String, Customer>і вона все одно працюватиме. У той же час контракт на отримання приймає Object, тому новий інтерфейс повинен підтримувати і цей контракт.

На мій погляд, вони повинні були додати новий інтерфейс і реалізовані як на існуючій колекції, але вони вирішили на користь сумісних інтерфейсів, навіть якщо це означає гірший дизайн для методу get. Зауважте, що самі колекції були б сумісні з існуючими методами, лише інтерфейси не були б.

Ми зараз робимо великий рефакторинг, і нам не вистачало цього сильно набраного get (), щоб перевірити, що ми не пропустили деякий get () зі старим типом.

Але я знайшов обхідний / некрасивий трюк для перевірки часу компіляції: створіть інтерфейс Map із сильно набраним get, міститьKey, видаліть ... та покладіть його на java.util пакет свого проекту.

Ви отримаєте помилки компіляції лише для виклику get (), ... з неправильними типами, все, що інше здається нормальним для компілятора (принаймні, всередині eclipse kepler).

Не забудьте видалити цей інтерфейс після перевірки вашої збірки, оскільки це не те, що потрібно під час виконання.