Nach meiner Meinung gibt es in Java kein Pair, weil, wenn Sie zusätzliche Funktionalitäten direkt auf das Pair hinzufügen möchten (z. B. Comparable), müssen Sie die Typen einschränken. In C++ ist es egal, und wenn die Typen, die ein Pair bilden, keinen operator < ```haben, wird auch der ``pair::operator < `nicht kompilieren.` `` ```
`
`
Ein Beispiel für Comparable ohne Einschränkung:
public class Pair implements Comparable> {
public final F first;
public final S second;
/* ... */
public int compareTo(Pair that) {
int cf = compare(first, that.first);
return cf == 0 ? compare(second, that.second) : cf;
}
//Warum wird entschieden, dass null kleiner als alles ist?
private static int compare(Object l, Object r) {
if (l == null) {
return r == null ? 0 : -1;
} else {
return r == null ? 1 : ((Comparable) (l)).compareTo(r);
}
}
}
/* ... */
Pair> a = /* ... */;
Pair> b = /* ... */;
//Laufzeitfehler hier anstatt Kompilierfehler!
System.out.println(a.compareTo(b));
Ein Beispiel für Comparable mit Kompilierzeitprüfung, ob Typargumente vergleichbar sind:
public class Pair<
F extends Comparable,
S extends Comparable
> implements Comparable> {
public final F first;
public final S second;
/* ... */
public int compareTo(Pair that) {
int cf = compare(first, that.first);
return cf == 0 ? compare(second, that.second) : cf;
}
//Warum wird entschieden, dass null kleiner als alles ist?
private static <
T extends Comparable
> int compare(T l, T r) {
if (l == null) {
return r == null ? 0 : -1;
} else {
return r == null ? 1 : l.compareTo(r);
}
}
}
/* ... */
//Wird nicht kompilieren, weil Thread nicht Comparable ist
Pair> a = /* ... */;
Pair> b = /* ... */;
System.out.println(a.compareTo(b));
Dies ist gut, aber dieses Mal dürfen Sie keine nicht vergleichbaren Typen als Typargumente in Pair verwenden. Man kann viele Comparators für Pair in einer Hilfsklasse verwenden, aber C++-Leute verstehen das vielleicht nicht. Ein anderer Weg ist, viele Klassen in einer Typenhierarchie mit unterschiedlichen Einschränkungen für Typargumente zu schreiben, aber es gibt zu viele mögliche Einschränkungen und ihre Kombinationen...
` `` ```
10 Stimmen
Warum ist
AbstractMap.SimpleEntry
umständlich?0 Stimmen
Sehen Sie meine Antwort stackoverflow.com/a/16089164/173149, wo ich AbstractMap.SimpleImmutableEntry ohne Probleme verwende (kompliziertes Beispiel).
0 Stimmen
SimpleEntry
hat drei Methoden, die nicht vonObject
vererbt wurden. Warum sollte es "verschachtelt" sein?29 Stimmen
Aufgrund der Namensgebung, willkürliche Benennung eines Schlüssels und eines Werts.
2 Stimmen
Siehe auch stackoverflow.com/questions/6271731/…
0 Stimmen
Wenn Sie Java 8 verwenden, löst
import javafx.util.Pair
Ihre Probleme.2 Stimmen
@sffc JavaFX ist in keinem der Standard-Classpaths in JDK7 vorhanden, für die Verwendung muss die JFX-Laufzeitbibliotheken manuell hinzugefügt werden.
4 Stimmen
@Enerccio: Also, du behauptest tatsächlich, dass "erstes" und "zweites" nicht willkürlich sind, während "Schlüssel" und "Wert" - ist? Dann ist das ein guter Grund dafür, eine solche Klasse nicht im SDK zu haben. Es würde einen ewigen Streit über die "richtige" Benennung geben.