Ich möcht ja nicht meckern, aber das ist kompletter Unsinn
Einmal hat das absolut nichts mit der Frage zu tun, in der es um Comparator geht, und andererseits ist der Stil echt schlecht.
return o.equals(c), und damit wäre die Methode im wesentlichen, eine vorhandene Methode in eine statische auszulagern und unsinnig zu benennen, die hat genau gar keinen Vorteil gegenüber o.equals(c), außer zusätzlichen Imports und schlechterer Lesbarkeit.public class Person {
int alter;
String name;
public Person(int alter, String name){
this.alter = alter;
this.name = name;
}
}Dir geht es um das Comparator-Interface?
compare(Person p1, Person p2) und müsste -1 zurückgeben, wenn p1 jünger als p2 ist, 0 wenn sie gleich alt sind und 1, wenn p1 älter als p2 ist?public int compare(Person p1, Person p2){
dann wirft er in der 3. zeile den fehler "unreachable code"
Fürs Lernen sind die schöner
Integer.compare nutzen, was wenig überraschend mit Vergleichen und nicht Subtraktion umgesetzt ist.Gewöhn dir an, das if mit Klammern zu schreiben.
Klar, nach der ersten Bedingung lieferst du ja einen Rückgabewert. Der Rest wird niemals ausgeführt. Der "Else" Fall kommt zum Schluss. Einen der 3 Fälle musst du nicht prüfen. Die Zahl ist entweder größer oder sie ist gleich ODER (else-Fall) sie ist kleiner (Reihenfolge wurscht). Wenn sie also weder größer noch kleiner ist, dann musst du nicht mehr prüfen, ob sie kleiner ist. Anstatt der 3. Bedingung musst du einfach den Rückgabewert derselben liefern.
/**
* relativ "saubere" Variante, allerdings werden mehrere 'return' verwendet, das sollten Anfänger nicht machen. V2 ist für Anfänger besser
*/
public int compareV1(Person p1, Person p2) {
if (p1.alter > p2.alter) {
return -1;
} else if (p1.alter < p2.alter) {
return 1;
} else {
//Auf Gleichheit musst du nicht mehr prüfen
return 0;
}
}
/**
* "sauberste" Variante, so wie man es lernen sollte.
*/
public int compareV2(Person p1, Person p2) {
//Beachte: returnvalue wird hier am Anfang nicht initialisiert, der Compiler warnt dich also, wenn du es auswerten willst, so lange noch kein Wert gesetzt ist.
int returnvalue;
if (p1.alter > p2.alter) {
returnvalue = -1;
} else if (p1.alter < p2.alter) {
returnvalue = 1;
} else {
//Auf Gleichheit musst du nicht mehr prüfen
returnvalue = 0;
}
//Erst an diesem Punkt hat returnvalue garantiert einen Wert und darf weiterverwendet werden.
return returnvalue;
}
/**
* Diese Variante hat weniger Else-Bereiche, ist als etwas resourcenschonender, liefert aber auch immer direkt das Ergebnis. Für Anfänger nicht geeignet.
*/
public int compareV3(Person p1, Person p2) {
if (p1.alter > p2.alter) {
return -1;
}
if (p1.alter < p2.alter) {
return 1;
}
//Auf Gleichheit musst du nicht mehr prüfen
return 0;
}
/**
* Für mehrere Vergleiche
*
* @param p1
* @param p2
* @return
*/
public int compareV4(Person p1, Person p2) {
//Kürzen wir das Ganze etwas ab, für Integer gibt es bereits eine Compare-Funktion, schau dir deren Quellcode mal an
int returnvalue = Integer.compare(p1.alter, p2.alter);
//Alter verschieden, Ergebnis liefern
if (returnvalue != 0) {
return returnvalue;
}
//Alter gleich, es muss weiter verglichen werden
returnvalue = compareTwoStrings(p1.name, p2.name);
//Keine weiteren Vergleichsoptionen vorhanden, also einfach den Wert liefern. Ansonsten hier returnValue wieder auf 0 prüfen und den nächsten Parameter prüfen
return returnvalue;
}
/**
* String-Vergleich ohne Nullpointer-Exception
* @param s1 String1
* @param s2 String2
* @return Beide Werte null: 0, s1 == null: 1, s2 == null: -1
*/
private int compareTwoStrings(String s1, String s2) {
if (s1 == null) {
//Wenn beide Namen auf null gesetzt sind, dann als "gleich" betrachten, also Ergebnis 0
//Nur p1.name == null ? 1
return s2 == null ? 0 : 1;
}
if (s2 == null) {
//nur p2.name == null? -1
return -1;
}
//ansonsten echt vergleichen lassen
return s1.compareTo(s2);
}Warum? Compiler warnt dich auch hier, dass ein Pfad nichts returned V2 ist äquivalent zu V1
Comparator::nullsFirst oder Comparator::nullsLast. Aber es sollte meiner Meinung nach da richtig krachen, denn welche Person hat denn keinen Namen?
Ersetzt man in seinem zu letz gepostetem Code das letzte if wie vorgeschlagen durch ein else, reicht das auch schon und kompiliert
Warum ... zum besseren Verständnis. Returns mitten in einer Methode sind mitunter eine recht unübersichtliche Art zu Arbeiten. Ein Anfänger sollte sich auf ein Return pro Methode beschränken und den Workflow verstehen, bevor er so was macht. Der Thread-Ersteller muss sich erst noch mit if-then-else beschäftigen und damit, was bei einem return passiert, sonst würde er diese Fragen nicht stellen (siehe "unreachable code").
Klar. Valider Zustand ist Sache der einzelnen Klassen. Aber in dem Fall sind null-aware Comparatoren etwas übertrieben.
Das seh ich aber genau umgekehrt. Frühes Verlassen einer Methode hat den Vorteil zu wissen, dass weiter nachfolgender Code nicht mehr ausgeführt wird und muss nicht sicherstellen (meist verbunden mit weiteren/redundanten if-Abfragen) das dieser nicht ausgeführt wird.
Es gibt hier nur eben KEINE Validierung bisher, also einfach nur eine Exception beim Sortieren.
Ich stimmer dir zu, dass das ein Vorteil ist (ich arbeite vor allem bei Vergleichsmthoden ja auch so), aber zum Lernen ist es besser, wenn man übt, die komplette Logik im Auge zu behalten. Gerade bei längeren Methoden sucht man sich sonst einen ab, alle returns zu finden.
Es gibt hier auch KEINE Testdaten, um zusehen ob
null eine Möglichkeit ist, also daher ... es ist nur ein Beispiel.
