Warum sind die Entfernungsmethoden von Java Collections nicht generisch?

Question 1

Warum nicht Collection.remove(Objekt o) generisch?

Sieht aus als ob Collection<E> könnte haben boolean remove(E o);

Wenn Sie dann versehentlich versuchen, (zum Beispiel) Set<String> statt jedem einzelnen String von a Collection<String>wäre es ein Kompilierzeitfehler und kein späteres Debugging-Problem.

Question 2

Josh Bloch und Bill Pugh beziehen sich auf dieses Problem in Java Puzzlers IV: The Phantom Reference Menace, Attack of the Clone und Revenge of The Shift.

Josh Bloch sagt (6:41), dass sie versucht haben, die get-Methode von Map, remove-Methode und einige andere zu generieren, aber “es hat einfach nicht funktioniert”.

Es gibt zu viele sinnvolle Programme, die nicht generiert werden könnten, wenn man als Parametertyp nur den generischen Typ der Collection zulässt. Das von ihm gegebene Beispiel ist ein Schnittpunkt von a List von Numbers und a
List von LongS.

Question 3

remove() (in Map sowie im Collection) ist nicht generisch, da Sie in der Lage sein sollten, jeden Objekttyp an zu übergeben remove(). Das entfernte Objekt muss nicht vom gleichen Typ sein wie das Objekt, an das Sie übergeben remove(); es erfordert nur, dass sie gleich sind. Aus der Spezifikation von remove(), remove(o) entfernt das Objekt e so dass (o==null ? e==null : o.equals(e)) ist true. Beachten Sie, dass nichts erforderlich ist o und e vom gleichen Typ sein. Dies ergibt sich daraus, dass die equals() Methode nimmt an Object als Parameter, nicht nur vom gleichen Typ wie das Objekt.

Obwohl es im Allgemeinen zutreffen kann, dass viele Klassen dies haben equals() so definiert, dass seine Objekte nur Objekten seiner eigenen Klasse gleich sein können, ist dies sicherlich nicht immer der Fall. 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 möglich, a zu haben Map<ArrayList, Something> und für mich anzurufen remove() mit einer LinkedList als Argument, und es sollte den Schlüssel entfernen, der eine Liste mit demselben Inhalt ist. Dies wäre nicht möglich, wenn remove() waren generisch und schränkten ihren Argumenttyp ein.

Question 4

Denn wenn Ihr Typparameter ein Platzhalter ist, können Sie keine generische Entfernungsmethode verwenden.

Ich meine mich zu erinnern, dass ich mit der get(Object)-Methode von Map auf diese Frage gestoßen bin. Die get-Methode ist in diesem Fall nicht generisch, obwohl sie vernünftigerweise erwarten sollte, dass ein Objekt desselben Typs wie der erste Typparameter übergeben wird. Mir wurde klar, dass es keine Möglichkeit gibt, mit dieser Methode ein Element aus der Map herauszubekommen, wenn Sie Maps mit einem Platzhalter als erstem Typparameter weitergeben, wenn dieses Argument generisch war. Wildcard-Argumente können nicht wirklich erfüllt werden, da der Compiler nicht garantieren kann, dass der Typ korrekt ist. Ich vermute, dass add generisch ist, weil von Ihnen erwartet wird, dass Sie garantieren, dass der Typ korrekt ist, bevor Sie ihn der Sammlung hinzufügen. Wenn jedoch beim Entfernen eines Objekts der Typ falsch ist, wird es sowieso nicht übereinstimmen. Wenn das Argument ein Platzhalter wäre, wäre die Methode einfach unbrauchbar, obwohl Sie möglicherweise ein Objekt haben, von dem Sie GARANTIEREN können, dass es zu dieser Sammlung gehört, weil Sie gerade in der vorherigen Zeile einen Verweis darauf erhalten haben ….

Ich habe es wahrscheinlich nicht sehr gut erklärt, aber es erscheint mir logisch genug.

Question 5

Neben den anderen Antworten gibt es noch einen weiteren Grund, warum die Methode an akzeptieren sollte Object, was Prädikate sind. Betrachten Sie das folgende Beispiel:

class Person {
    public String name;
    // override equals()
}
class Employee extends Person {
    public String company;
    // override equals()
}
class Developer extends Employee {
    public int yearsOfExperience;
    // override equals()
}

class Test {
    public static void main(String[] args) {
        Collection<? extends Person> people = new ArrayList<Employee>();
        // ...

        // to remove the first employee with a specific name:
        people.remove(new Person(someName1));

        // to remove the first developer that matches some criteria:
        people.remove(new Developer(someName2, someCompany, 10));

        // to remove the first employee who is either
        // a developer or an employee of someCompany:
        people.remove(new Object() {
            public boolean equals(Object employee) {
                return employee instanceof Developer
                    || ((Employee) employee).company.equals(someCompany);
        }});
    }
}

Der Punkt ist, dass das Objekt an die übergeben wird remove Methode ist für die Definition von verantwortlich equals Methode. Das Erstellen von Prädikaten wird auf diese Weise sehr einfach.

Question 6

Angenommen, man hat eine Sammlung von Catund einige Objektreferenzen von Typen Animal, Cat, SiameseCatund Dog. Abfragen der Auflistung, ob sie das Objekt enthält, auf das durch die verwiesen wird Cat oder SiameseCat Referenz erscheint sinnvoll. Abfragen, ob es das Objekt enthält, auf das durch die verwiesen wird Animal Referenz mag zwielichtig erscheinen, aber es ist immer noch vollkommen vernünftig. Das fragliche Objekt könnte schließlich a sein Catund kann in der Sammlung erscheinen.

Auch wenn das Objekt zufällig etwas anderes als a ist Cat, gibt es kein Problem zu sagen, ob es in der Sammlung erscheint – antworten Sie einfach mit „nein, tut es nicht“. Eine Sammlung irgendeines Typs im “Lookup-Stil” sollte in der Lage sein, Verweise auf beliebige Supertypen sinnvoll zu akzeptieren und festzustellen, ob das Objekt in der Sammlung existiert. Wenn die übergebene Objektreferenz von einem nicht verwandten Typ ist, kann die Sammlung sie auf keinen Fall enthalten, sodass die Abfrage in gewissem Sinne nicht sinnvoll ist (sie wird immer mit „nein“ antworten). Da es jedoch keine Möglichkeit gibt, Parameter auf Subtypen oder Supertypen zu beschränken, ist es am praktischsten, einfach jeden Typ zu akzeptieren und für alle Objekte, deren Typ nichts mit dem der Sammlung zu tun hat, mit “Nein” zu antworten.

Question 7

Ich dachte immer, das liegt daran, dass remove() keinen Grund hat, sich darum zu kümmern, welche Art von Objekt Sie ihm geben. Es ist trotzdem einfach genug zu überprüfen, ob dieses Objekt eines der Objekte ist, die die Collection enthält, da es equals() für alles aufrufen kann. Es ist notwendig, den Typ bei add() zu überprüfen, um sicherzustellen, dass er nur Objekte dieses Typs enthält.

Question 8

Es war ein Kompromiss. Beide Vorgehensweisen haben ihren Vorteil:

remove(Object o)
- ist flexibler. Zum Beispiel ermöglicht es, eine Liste von Zahlen zu durchlaufen und sie aus einer Liste von Longs zu entfernen.
- Code, der diese Flexibilität nutzt, kann einfacher generiert werden
remove(E e) bringt mehr Typsicherheit in das, was die meisten Programme tun möchten, indem sie subtile Fehler zur Kompilierzeit erkennen, wie z.

Abwärtskompatibilität war immer ein Hauptziel bei der Weiterentwicklung der Java-API, daher wurde remove(Object o) gewählt, weil es das Generieren von vorhandenem Code erleichtert. Wenn Abwärtskompatibilität KEIN Problem gewesen wäre, schätze ich, dass die Designer remove(E e) gewählt hätten.