Warum wurden die Methoden von Collections nicht in AbstractCollection aufgenommen?

Question

Ich frage mich, warum die Klasse Collections wurde erstellt. Theoretisch könnten die Methoden dieser Klasse in die Klasse AbstractCollection . Was war also der Grund für die Schaffung einer separaten Utility-Klasse?

Answer 1

1. Nicht jede Sammlung erweitert AbstractCollection und diese Methoden sind dort immer noch anwendbar.
2. Zu viele Methoden in einer Klasse erschweren das Verständnis dieser Klasse, wenn man sich durch die Javadoc arbeitet.
3. Wenn Sie eine E-Mail erhalten Collection von einem nicht vertrauenswürdigen Aufrufer, wobei Sie sicherstellen müssen, dass Sie immer dieselbe Implementierung von z. B. unmodifiableCollection kann hilfreich sein.
4. Meistens behält man den genauen Implementierungstyp von Sammlungen nicht im Auge: Man schreibt zum Beispiel Set<E> set = new HashSet<>(); In diesem Fall können Sie keine der Methoden verwenden, die in AbstractCollection die nicht in Collection .

Answer 2

Es kann vorkommen, dass Sie ein unabhängiges Objekt implementieren wollen, das das der Collection Schnittstelle, ohne AbstractCollection zu erweitern.

Zum Beispiel: http://commons.apache.org/collections/api-release/org/apache/commons/collections/bag/HashBag.html

Answer 3

Wenn die JDK-Leute beschließen, dass sie der Klasse Collections weitere Methoden hinzufügen wollen, müssen sie diese einfach implementieren. newSetFromMap wurde beispielsweise in Version 1.6 hinzugefügt. Es ist nicht möglich, der Collection-Schnittstelle weitere Methoden hinzuzufügen und die Abwärtskompatibilität aufrechtzuerhalten, da, wie Louis Wasserman sagte, nicht alle Collections AbstractCollection erweitern - insbesondere die von Drittanbietern, die Teil von Guava, Commons Collections, Hibernate, OpenJPA usw. sind.

In Sprachen, die Mixins anstelle von Schnittstellen haben, ist dies nicht so ein großes Problem. Scala zum Beispiel hat eine riesige Anzahl von Methoden für seine Sammlungen. Und zwar so viele, dass man auf Louis Wassermans zweites Problem stößt: schwer lesbare Javadocs (in diesem Fall Scaladocs).