Was sind die Gründe, warum Map.get (Objektschlüssel) nicht (vollständig) generisch ist

Question 1

Was sind die Gründe für die Entscheidung, keine vollständig generische get-Methode in der Schnittstelle von zu haben? java.util.Map<K, V>.

Um die Frage zu klären, ist die Signatur der Methode

V get(Object key)

anstatt

V get(K key)

und ich frage mich warum (das gleiche für remove, containsKey, containsValue).

Question 2

Wie von anderen erwähnt, der Grund warum get()usw. ist nicht generisch, da der Schlüssel des Eintrags, den Sie abrufen, nicht vom gleichen Typ sein muss wie das Objekt, an das Sie übergeben get(); die Spezifikation der Methode verlangt lediglich, dass sie gleich sind. Dies folgt daraus, wie die equals() -Methode nimmt ein Objekt als Parameter auf, nicht nur den gleichen Typ wie das Objekt.

Obwohl es im Allgemeinen zutreffen mag, dass viele Klassen dies haben equals() so definiert ist, dass seine Objekte nur Objekten seiner eigenen Klasse entsprechen können, gibt es viele Stellen in Java, an denen dies nicht der Fall ist. Zum Beispiel die Spezifikation für List.equals() sagt, dass zwei List-Objekte gleich sind, wenn sie beide Listen sind und denselben Inhalt haben, auch wenn sie unterschiedliche Implementierungen von sind List. Um auf das Beispiel in dieser Frage zurückzukommen, ist es gemäß der Spezifikation der Methode möglich, a zu haben Map<ArrayList, Something> und für mich anzurufen get() mit einer LinkedList als Argument, und es sollte den Schlüssel abrufen, der eine Liste mit demselben Inhalt ist. Dies wäre nicht möglich, wenn get() waren generisch und schränkten ihren Argumenttyp ein.

Question 3

Ein großartiger Java-Programmierer bei Google, Kevin Bourrillion, schrieb über genau dieses Problem in a Blogeintrag vor einiger Zeit (allerdings im Kontext von Set anstatt Map). Der relevanteste Satz:

Methoden des Java Collections Framework (und auch der Google Collections Library) schränken einheitlich die Typen ihrer Parameter niemals ein, es sei denn, es ist notwendig, um zu verhindern, dass die Sammlung beschädigt wird.

Ich bin mir nicht ganz sicher, ob ich grundsätzlich damit einverstanden bin – .NET scheint zum Beispiel in Ordnung zu sein, wenn der richtige Schlüsseltyp erforderlich ist – aber es lohnt sich, der Argumentation im Blogbeitrag zu folgen. (Nachdem .NET erwähnt wurde, lohnt es sich zu erklären, dass ein Teil des Grundes, warum es in .NET kein Problem darstellt, darin besteht, dass es die größer Problem in .NET mit begrenzter Varianz …)

Question 4

Der Vertrag wird so ausgedrückt:

Wenn diese Abbildung formaler eine Abbildung von einem Schlüssel k auf einen Wert v enthält, so dass (key==null ? k==null :
key.equals(k)), dann gibt diese Methode v zurück; andernfalls wird null zurückgegeben. (Es kann höchstens eine solche Zuordnung geben.)

(meine Betonung)

Daher hängt eine erfolgreiche Schlüsselsuche von der Implementierung der Gleichheitsmethode durch den Eingabeschlüssel ab. Das ist nicht Notwendig abhängig von der Klasse von k.

Question 5

Es ist eine Anwendung von Postelsches Gesetz, „sei konservativ in dem, was du tust, sei liberal in dem, was du von anderen akzeptierst.“

Gleichheitsprüfungen können unabhängig vom Typ durchgeführt werden; der equals Methode ist auf der definiert Object Klasse und akzeptiert alle Object als Parameter. Daher ist es für Schlüsseläquivalenz und Operationen, die auf Schlüsseläquivalenz basieren, sinnvoll, alle zu akzeptieren Object Art.

Wenn eine Zuordnung Schlüsselwerte zurückgibt, behält sie so viele Typinformationen wie möglich bei, indem sie den Typparameter verwendet.

Question 6

Ich denke, dieser Abschnitt des Generika-Tutorials erklärt die Situation (meine Betonung):

“Sie müssen sicherstellen, dass die generische API nicht übermäßig restriktiv ist; sie muss weiterhin den ursprünglichen Vertrag der API unterstützen. Betrachten Sie noch einmal einige Beispiele aus java.util.Collection. Die vorgenerische API sieht folgendermaßen aus:

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

Ein naiver Versuch, es zu generieren, ist:

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

Obwohl dies sicherlich typsicher ist, entspricht es nicht dem ursprünglichen Vertrag der API.
Die Methode containsAll() funktioniert mit jeder Art von eingehender Sammlung. Es wird nur erfolgreich sein, wenn die eingehende Sammlung wirklich nur Instanzen von E enthält, aber:

Der statische Typ der eingehenden Auflistung kann sich unterscheiden, möglicherweise weil der Aufrufer den genauen Typ der übergebenen Auflistung nicht kennt oder weil es sich um eine Collection ~~handelt, wobei S ein Untertyp von E ist.~~

~~Es ist völlig legitim, containsAll() mit einer Sammlung eines anderen Typs aufzurufen. Die Routine sollte funktionieren und false zurückgeben.”~~

Question 7

Der Grund dafür ist, dass die Eindämmung durch bestimmt wird equals und hashCode welche Methoden sind auf Object und beide nehmen ein Object Parameter. Dies war ein früher Designfehler in den Standardbibliotheken von Java. In Verbindung mit Einschränkungen im Typsystem von Java zwingt es alles, was auf equals und hashCode angewiesen ist, zu nehmen Object.

Die einzige Möglichkeit, typsichere Hash-Tabellen und Gleichheit in Java zu haben, besteht darin, sie zu vermeiden Object.equals und Object.hashCode und verwenden Sie einen generischen Ersatz. Funktionales Java enthält Typklassen für genau diesen Zweck: Hash<A> und Equal<A>. Eine Hülle für HashMap<K, V> vorgesehen ist, dauert Hash<K> und Equal<K> in seinem Konstruktor. Die dieser Klasse get und contains Methoden nehmen daher ein generisches Typ-Argument entgegen K.

Beispiel:

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

Question 8

Kompatibilität.

Bevor Generika verfügbar waren, gab es nur get(Object o).

Hätten sie diese Methode in get( o) geändert, hätte dies den Java-Benutzern möglicherweise eine massive Codewartung aufgezwungen, nur um den funktionierenden Code erneut zu kompilieren.

Sie könnten haben eine eingeführt zusätzlich sagen Sie get_checked( o) und verwerfen Sie die alte Methode get(), damit es einen sanfteren Übergangspfad gibt. Aber aus irgendeinem Grund wurde dies nicht getan. (Die Situation, in der wir uns jetzt befinden, ist, dass Sie Tools wie findBugs installieren müssen, um die Typkompatibilität zwischen dem Argument get() und dem deklarierten Schlüsseltyp der Karte zu überprüfen.)

Die Argumente bezüglich der Semantik von .equals() sind meines Erachtens falsch. (Technisch gesehen sind sie korrekt, aber ich denke immer noch, dass sie falsch sind. Kein Designer, der bei klarem Verstand ist, wird jemals o1.equals(o2) wahr machen, wenn o1 und o2 keine gemeinsame Oberklasse haben.)