Jakie są powody, dla których Map.get (klucz obiektu) nie jest (w pełni) ogólny

Jakie są przyczyny decyzji o braku w pełni ogólnej metody get w interfejsie java.util.Map<K, V>.

Aby wyjaśnić pytanie, podpisem metody jest

V get(Object key)

zamiast

V get(K key)

i zastanawiam się, dlaczego (to samo remove, containsKey, containsValue).

Jak wspomnieli inni, powód, dla którego get()itp. Nie jest ogólny, ponieważ klucz wpisu, który pobierasz, nie musi być tego samego typu co obiekt, do którego przekazujesz get(); specyfikacja metody wymaga tylko, aby były one równe. Wynika to ze sposobu, w jaki equals()metoda przyjmuje obiekt jako parametr, a nie tylko tego samego typu co obiekt.

Chociaż może być prawdą, że wiele klas equals()zdefiniowało tak, że jej obiekty mogą być równe tylko obiektom własnej klasy, w Javie jest wiele miejsc, w których tak nie jest. Na przykład specyfikacja dla List.equals()mówi, że dwa obiekty List są równe, jeśli oba są Listami i mają tę samą zawartość, nawet jeśli są różnymi implementacjami List. Wracając do przykładu w tym pytaniu, zgodnie ze specyfikacją metody, możliwe jest Map<ArrayList, Something>wywołanie a dla mnie get()z LinkedListargumentem as, i powinien on pobrać klucz, który jest listą o tej samej zawartości. Nie byłoby to możliwe, gdyby get()były ogólne i ograniczyłyby typ argumentu.

Niesamowity programista Java w Google, Kevin Bourrillion, pisał o tym właśnie problemie w blogu jakiś czas temu (co prawda w kontekście Setzamiast Map). Najważniejsze zdanie:

Jednakowo metody Java Collections Framework (a także Biblioteka Google Maps Library) nigdy nie ograniczają rodzajów ich parametrów, z wyjątkiem sytuacji, gdy jest to konieczne, aby zapobiec uszkodzeniu kolekcji.

Nie jestem do końca pewien, czy zgadzam się z tym co do zasady - .NET wydaje się być w porządku, wymagając na przykład odpowiedniego typu klucza - ale warto podążać za rozumowaniem w poście na blogu. (Wspomniawszy o .NET, warto wyjaśnić tę część powodu, dla którego nie jest to problem w .NET, ponieważ jest większy problem w .NET o bardziej ograniczonej wariancji ...)

Umowa jest wyrażona w następujący sposób:

Bardziej formalnie, jeśli ta mapa zawiera mapowanie z klucza k na wartość v taką, że (klucz == null? K == null: key.equals (k) ), wówczas ta metoda zwraca v; w przeciwnym razie zwraca null. (Może być maksymalnie jedno takie mapowanie).

(mój nacisk)

i jako takie, pomyślne wyszukiwanie klucza zależy od implementacji metody równości w kluczu wejściowym. Nie jest niekoniecznie zależy od klasy k.

Jest to zastosowanie prawa Postela: „bądź konserwatywny w tym, co robisz, bądź liberalny w tym, co akceptujesz od innych”.

Kontrole równości można przeprowadzać niezależnie od rodzaju; equalssposób określa się na Objectklasy i przyjmuje każdy Objectjako parametr. Tak więc sensowne jest, aby akceptować dowolność klucza i operacje oparte na równoważności kluczaObject typ.

Kiedy mapa zwraca kluczowe wartości, zachowuje tyle informacji o typie, ile może, używając parametru type.

Myślę, że ta sekcja samouczka generycznego wyjaśnia sytuację (mój nacisk):

„Musisz upewnić się, że ogólny interfejs API nie jest nadmiernie restrykcyjny; musi nadal obsługiwać pierwotną umowę API. Ponownie rozważ kilka przykładów z java.util.Collection. Wstępnie ogólny interfejs API wygląda następująco:

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

Naiwna próba jej wygenerowania to:

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

Chociaż jest to z pewnością bezpieczne dla typu, nie jest zgodne z pierwotną umową API. Metoda zawieraAll () działa z każdym rodzajem kolekcji przychodzącej. Uda się to tylko wtedy, gdy przychodząca kolekcja naprawdę zawiera tylko instancje E, ale:

• Statyczny typ kolekcji przychodzącej może się różnić, być może dlatego, że wywołujący nie zna dokładnego typu przekazywanej kolekcji, a może dlatego, że jest to kolekcja <S>, gdzie S jest podtypem E.
• Wywołanie funkcji zawieraAll () z kolekcją innego typu jest całkowicie uzasadnione. Procedura powinna działać, zwracając wartość false. ”

Powodem jest to, że ograniczenie jest określane przez equalsi hashCodektóre metody są włączone Objecti oba przyjmują Objectparametr. To była wczesna wada projektowa w standardowych bibliotekach Java. W połączeniu z ograniczeniami w systemie typów Java, wymusza wszystko, co zależy od equals i hashCodeObject .

Jedynym sposobem, aby mieć bezpieczny typu tabele mieszania i równości w Javie jest wystrzegać Object.equalsi Object.hashCodei używać rodzajowe substytut. Funkcjonalna Java jest dostarczana z klasami tylko w tym celu: Hash<A>i Equal<A>. Zapewnione HashMap<K, V>jest opakowanie dla, które pobiera Hash<K>i Equal<K>jego konstruktora. Dlatego te klasy geti containsmetody przyjmują ogólny argument typuK .

Przykład:

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

Zgodność.

Zanim dostępne były leki generyczne, pojawiło się tylko (Obiekt o).

Gdyby zmienili tę metodę, aby uzyskać (<K> o), potencjalnie zmusiłoby to masową konserwację kodu do użytkowników Java, aby ponownie skompilować działający kod.

Oni mogli wprowadziliśmy dodatkowy sposób, powiedzmy get_checked (<K> O) i deprecate sposób stary get (), więc był łagodniejszy ścieżki przejścia. Ale z jakiegoś powodu tego nie zrobiono. (Obecna sytuacja polega na tym, że musisz zainstalować narzędzia takie jak findBugs, aby sprawdzić zgodność typu między argumentem get () a zadeklarowanym typem klucza <K> mapy).

Argumenty dotyczące semantyki .equals () są, jak sądzę, fałszywe. (Technicznie są poprawne, ale nadal uważam, że są fałszywe. Żaden projektant przy zdrowych zmysłach nigdy nie sprawi, że o1. Równe (o2) będą prawdziwe, jeśli o1 i o2 nie będą miały żadnej wspólnej nadklasy.)

Jest jeszcze jeden ważny powód, którego nie można zrobić technicznie, ponieważ psuje mapę.

Java ma polimorficzną ogólną budowę podobną do <? extends SomeClass>. Oznaczone takie odniesienie może wskazywać na typ podpisany za pomocą <AnySubclassOfSomeClass>. Ale polimorficzny rodzajowy sprawia, że ​​odniesienie jest tylko do odczytu . Kompilator pozwala używać typów ogólnych tylko jako zwracanej metody (jak proste metody pobierające), ale blokuje metody, w których typem ogólnym jest argument (jak zwykłe ustawiacze). Oznacza to, że jeśli napiszesz Map<? extends KeyType, ValueType>, kompilator nie pozwala na wywołanie metody get(<? extends KeyType>), a mapa będzie bezużyteczna. Jedynym rozwiązaniem jest, aby metoda ta ogólna: get(Object).

Chyba kompatybilność wsteczna. Map(lub HashMap) nadal musi wspierać get(Object).

Patrzyłem na to i myślałem, dlaczego to zrobili w ten sposób. Nie sądzę, żeby którakolwiek z istniejących odpowiedzi wyjaśniała, dlaczego nie mogli po prostu sprawić, aby nowy ogólny interfejs akceptował tylko odpowiedni typ klucza. Rzeczywisty powód jest taki, że chociaż wprowadzili leki generyczne, NIE utworzyli nowego interfejsu. Interfejs mapy jest tą samą starą nie-ogólną mapą, która służy tylko jako wersja ogólna i ogólna. W ten sposób, jeśli masz metodę, która akceptuje mapę ogólną, możesz ją przekazać Map<String, Customer>i nadal będzie działać. Jednocześnie umowa get get przyjmuje Object, więc nowy interfejs powinien również obsługiwać tę umowę.

Moim zdaniem powinni oni dodać nowy interfejs i zaimplementować oba w istniejącej kolekcji, ale zdecydowali się na kompatybilne interfejsy, nawet jeśli oznacza to gorszy projekt dla metody get. Zauważ, że same kolekcje byłyby kompatybilne z istniejącymi metodami, których nie byłyby dostępne tylko interfejsy.

Obecnie dokonujemy dużego refaktoryzacji i brakowało nam tego mocno wpisanego get (), aby sprawdzić, czy nie przegapiliśmy trochę get () ze starym typem.

Ale znalazłem obejście / brzydką sztuczkę sprawdzania czasu kompilacji: utwórz interfejs mapy z silnie wpisanym get, zawiera klucz, usuń ... i umieść go w pakiecie java.util twojego projektu.

Otrzymasz błędy kompilacji tylko przy wywołaniu get (), ... przy niewłaściwych typach, wszystko inne wydaje się w porządku dla kompilatora (przynajmniej wewnątrz keplera zaćmienia).

Nie zapomnij usunąć tego interfejsu po sprawdzeniu kompilacji, ponieważ nie jest to pożądane w środowisku wykonawczym.