Warum entfernt Java TreeSetE (Object) kein E?

8

Aus dem Java 6 TreeSet<E> Dokumentation:

%Vor%

Warum akzeptiert dies ein Objekt anstelle des generischen Typs E? Die einzigen Objekte, die hinzugefügt werden können, sind vom Typ E, daher folgt, dass der einzige entfernbare Typ vom Typ E sein sollte.

    
ComputerDruid 04.11.2011, 21:06
quelle

4 Antworten

4

remove() , wie get() , muss funktionieren, wenn ein gleich -Element angegeben wird (in .equals() ). In Java ist es möglich (und in einigen Fällen erforderlich), dass Objekte verschiedener Klassen gleich sind. Daher sollten Sie den Typ nicht einschränken.

    
newacct 05.11.2011, 02:18
quelle
9

Nehmen wir die Antwort aus dem ersten Kommentar:

Mythos:

  

Ein beliebter Mythos ist, dass es dumm und böse ist, aber es war   notwendig wegen der Abwärtskompatibilität. Aber die Kompatibilität   Argument ist irrelevant; Die API ist korrekt, ob Sie es in Betracht ziehen   Kompatibilität oder nicht.

Wirklicher Grund:

  

Einheitlich, Methoden des Java Collections Framework (und der Google   (Auch die Sammlungsbibliothek) schränkt niemals die Arten ihrer Parameter ein   außer wenn es notwendig ist, zu verhindern, dass die Sammlung ankommt   gebrochen.

Lesen Sie hier mehr: Warum tut Set.contains () nimm ein Objekt, kein E?

    
zengr 04.11.2011 21:16
quelle
0

Nun, jedes E ist auch ein Objekt, und vielleicht hast du das E im Moment nicht als E (z. B. von einer Ereignisquelle), was es für dich praktisch macht. Andernfalls müssen Sie es nur auf E umwandeln, um es zu entfernen.

Aus Gleichheitssicht ist das egal: Die Referenzadresse des gegebenen Objekts wird getestet, wenn es dem Inhalt einer Menge entspricht, also ist es egal, welche Klasse es ist.

    
Alex Schenkel 04.11.2011 21:09
quelle
0

Das ist in der Tat ein Problem. Wenn jemand remove(o) aufruft und o 's nicht E ist, ist es normalerweise ein Programmierfehler, der versucht, die falsche Sache zu entfernen. Die Typprüfung konnte uns nicht vor dem Fehler schützen.

Obwohl eine gute IDE (IntelliJ) solche Probleme erkennen und uns warnen kann, sollten API-Designer eine präzisere Signatur bereitstellen, um die Überprüfung des Compiler-Typs zu verwenden. (IDE-Cheats hier - es weiß die Bedeutung von Set.remove() , weil es eine Standard-API ist. IDE bietet nicht die gleiche Hilfe für benutzerdefinierte APIs)

Für die Abfrage-API wie contains() ist es OK, ein Argument nicht E zu akzeptieren und ein trivial false zurückzugeben. So können wir beide haben %Vor%

Bei einer Mutations-API wie remove() ist fraglich, ob sie ein Argument nicht E akzeptieren soll. Die Debatte wird jedoch strittig sein angesichts der Realität der Löschung - es gibt wirklich keine andere Wahl, als ein Nicht-E-Argument zu akzeptieren und darüber Stillschweigen zu bewahren. Immer noch können wir zwei Methoden haben

%Vor%

In den meisten Fällen können Programmierer contains2/remove2 für zusätzliche Typsicherheit aufrufen.

    
irreputable 05.11.2011 02:22
quelle

Tags und Links