Warum haben wir enthält (Objekt o) statt enthält (e e)?

Question

Ist die Rückwärtskompatibilität mit älteren (nicht generischen) Versionen von Collection aufrechtzuerhalten? Oder gibt es ein subtileres Detail, das mir fehlt? Ich sehe dieses Muster wiederholt in remove auch (remove(Object o)), aber add wird als add(E e) generalisiert.

Answer 1

benötigt eine Object, weil das Objekt, mit dem es übereinstimmt, nicht vom selben Typ sein muss wie das Objekt, das Sie an übergeben; es erfordert nur, dass sie gleich sind. Von der Spezifikation gibt contains(o) den Wert true zurück, wenn ein Objekt e vorhanden ist, so dass (o==null ? e==null : o.equals(e)) wahr ist.Beachten Sie, dass nichts o und e vom gleichen Typ sein muss. Dies ergibt sich aus der Tatsache, dass die equals()-Methode einen Object als Parameter verwendet, nicht nur den gleichen Typ wie das Objekt.

Obwohl es allgemein zutreffend sein kann, dass viele Klassen equals() definiert haben, so dass ihre Objekte nur Objekten ihrer eigenen Klasse entsprechen können, ist das sicherlich nicht immer der Fall. Zum Beispiel sagt die Spezifikation für List.equals(), dass zwei List Objekte gleich sind, wenn sie beide List s sind und den gleichen Inhalt haben, auch wenn sie verschiedene Implementierungen von List sind. Also zurück zu dem Beispiel in dieser Frage, ist es möglich, eine Collection<ArrayList> und für mich mit einem LinkedList als Argument zu haben, und es möglicherweise True zurückgegeben, wenn es eine Liste mit dem gleichen Inhalt ist. Dies wäre nicht möglich, wenn generisch wäre und sein Argumenttyp auf E beschränkt wäre.

In der Tat, die Tatsache, dass jedes Objekt als Argument erlaubt eine interessante Anwendung, wo Sie können, um es für die Existenz eines Objekts in der Sammlung zu testen, die eine bestimmte Eigenschaft erfüllt:

Collection<Integer> integers; 
boolean oddNumberExists = integers.contains(new Object() { 
    public boolean equals(Object e) { 
     Integer i = (Integer)e; 
     if (i % 2 != 0) return true; 
     else return false; 
    } 
}); 

Answer 2

Es ist, weil die contains Funktion die equals Funktion nutzt, und die equals Funktion in der Basisobjektklasse mit einer Signatur von equals(Object o) anstatt equals(E e) definiert (da nicht alle Klassen sind generisch). Gleicher Fall mit der Funktion remove - es durchläuft die Sammlung mit der equals-Funktion, die ein Object-Argument übernimmt.

Dies erklärt die Entscheidung jedoch nicht direkt, da sie möglicherweise noch den Typ E verwendet hätten und es automatisch für die Eingabe von Object beim Aufruf von equals umgewandelt hätte; aber ich stelle mir vor, sie wollten die Funktion für andere Objekttypen aufrufen lassen. Es ist nichts falsch daran, eine Collection<Foo> c; und dann rufen c.contains(somethingOfTypeBar) - es wird immer falsch, und so beseitigt es die Notwendigkeit für eine Besetzung zu Foo (die eine Ausnahme auslösen kann) oder, um vor der Ausnahme zu schützen, eine typeof Anruf. Sie können sich also vorstellen, wenn Sie über etwas mit gemischten Typen iterieren und contains für jedes der Elemente aufrufen, können Sie einfach die contains-Funktion für alle verwenden, anstatt Wächter zu benötigen.

Es ist eigentlich erinnert an den „neueren“ lose typisierte Sprachen, wenn Sie es sehen auf diese Weise ...

Answer 3

hier beantwortet.
Why aren't Java Collections remove methods generic?
Kurz gesagt, sie wollten die Rückwärtskompatibilität maximieren, weil Sammlungen lange vor Generika eingeführt wurden.

Und von mir hinzufügen: das Video, das er bezieht, ist es wert, zu sehen.
http://www.youtube.com/watch?v=wDN_EYUvUq0

Update
Um zu klären, der Mann, der sagte, dass (im Video) war einer der Menschen, die Java-Karten und Sammlungen aktualisiert Generika zu verwenden. Wenn er es nicht weiß, wer dann?

Answer 4

Da es sonst nur mit der genauen Übereinstimmung des Parametertyps verglichen werden könnte, hätten speziell wildbehinderte Sammlungen nicht mehr funktioniert, z.

class Base 
{ 
} 

class Derived 
    extends Base 
{ 
} 

Collection< ? extends Base > c = ...; 

Derived d = ...; 

Base base_ref = d; 

c.contains(d); // Would have produced compile error 

c.contains(base_ref); // Would have produced compile error 

EDIT
Für Zweifler, die denken, das ist nicht einer der Gründe dafür, hier wird eine modifizierte Array-Liste mit einem generified würde enthält Methode

class MyCollection<E> extends ArrayList<E> 
{ 
    public boolean myContains(E e) 
    { 
     return false; 
    } 
} 

MyCollecttion< ? extends Base > c2 = ...; 

c2.myContains(d); // does not compile 
c2.myContains(base_ref); // does not compile 

Grundsätzlich contains(Object o) ist ein Hack zu machen dieser sehr häufige Anwendungsfall, um mit Java Generics zu arbeiten.

Answer 5

"enthält dieser Korb Äpfel diese Orange?"

klar eine echte Antwort kann nicht gegeben werden. aber das lässt immer noch zu möglichkeiten:

1. die antwort ist FALSCH.
2. die Frage ist nicht gut gebildet, sollte es nicht kompilieren übergeben.

die Sammlung api wählte die erste. aber die 2. Wahl wäre auch vollkommen sinnvoll. Eine Frage wie diese ist 99,99% der Fälle eine Schwachsinnfrage, also fragt nicht einmal!