Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Hallo Leute,
nach einiger Zeit mal wieder eine Frage... vermutlich total blöde aber mein Gehirn verknotet sich und ich stehe auf dem Schlauch.
Wann und warum haben Methoden Rückgabewerte wie 0 oder 1, wenn ich diese integer gar nicht weiter benötige? Platzhalter? Oder haben sie das gar nicht und ich habe etwas falsch verstanden? Insbesondere der RÜckgabewert 0 verwirrt mich da.
Ich kenne es bisher so, dass ich einen integer Rückgabewert dann verwende, bspw. in einem switch-case oder so, um je nach Rückgabewert eine andere Methode aufzurufen oder ähnliches.
Hoffe das war verständlich
Danke und schonmal liebe Grüße
als beispiel
bei comapre to ist es "festgelegt" wie man mit den werten hantieren soll
Compares this object with the specified object for order. Returns a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.
kann vllt auch sein dass daran die enums schuld haben ( maybe ? )
du hast ja auch in swing noch komponenten wo du werte mit "konstanten" setzt hinter denen stecken aber eig integer
man könnte diese heutzutage wahrscheinlich besser mit enums umsetzen aber warum sollte man alles umwuchten..
für compare to hätte man ja auch
Java:
enum Val{
GREATER,EQUALS,LESS;
}
benutzen können .. hinter enums stehen ja auch zahlen, i c++ und c# kann man enum werte in int casten und funktioniert weis auch nicht warum man das wie wann wo gemacht hat
wird sich schon irgendjemand was dabei gedacht haben .. aber das nur als fun nebenbei
Wann? Wenn der Entwickler der Methode sich dafür entschieden hat.
Warum? Weil der Entwickler irgendeinen Grund für seine Entscheidung sieht.
Ob Du den Rückgabewert benötigst bzw. verwendest, weiß der Entwickler nicht.
Das hört sich etwas dämlich an, ist aber tatsächlich so. Es ist reine Definitionssache.
Wenn der Entwickler keinen äußeren Zwängen unterliegt, kann er sich frei entscheiden, was er tut. Wenn ich will, nehme ich statt void als Rückgabetyp int und gebe immer 0 zurück. Ob das sinnvoll ist, steht auf einem anderen Blatt und darauf wirst Du hinaus wollen.
Nehmen wir mal ein Beispiel: die lastIndexOf-Methode von java.lang.String. Die liefert den Index des letzten Vorkommens eines gegebenen Zeichens im String, -1, wenn das Zeichen nicht im String enthalten ist.
Ist -1 sinnvoll? Eine negative Zahl ist in jedem Fall sinnvoll, weil ein Index nicht negativ sein kann. Hätte man auch -2 nehmen können? Sicher, nur für irgendwas muss man sich entscheiden und mit der -1 lässt sich z. B. einfach schreiben:
Java:
int ix = str.length() - 1;
while (ix >= 0 && str.chatAt(ix) != ch) {
ix--;
}
return ix;
Wenn das gesuchte Zeichen ch nicht im String str enthalten ist, dann läuft die Schleife so lange, bis ix >= 0 gerade nicht mehr gilt und das ist der Fall, wenn ix == -1 gilt.
Anderes Beispiel: wenn Du aus einem InputStream liest, liefert die read()-Methode -1, wenn keine weiteren Zeichen vorhanden sind. Ist das sinnvoll? Sicher, denn ein Byte bewegt sich nur im Bereich zwischen 0 und 255. Hätte man dann nicht auch 256 verwenden können? Klar, aber das wäre ungünstig, denn vielleicht will man ja ein Zeichen lesen (Reader) und dort bewegt man sich schon im Wertebereich zwischen 0 und 65535. Also ist eine negative Zahl auch hier nicht die schlechteste Wahl und -1 ist halt schöner als -321.
Math.signum() liefert (allerdings als double) das "Vorzeichen": -1 falls eine Zahl negativ ist, 0, falls die Zahl 0 ist und 1, falls die Zahl positiv ist (und NaN, falls es keine Zahl (NaN) ist). Hier sind die Konstanten wichtig, ansonsten könnte man ja gleich die Zahl direkt verwenden. Damit lassen sich Rechnungen vereinfachen.
Nein, denn compare liefert gerade keine Konstanten sondern nur negative oder positive Zahlen bzw. die 0. Das hat den Vorteil, dass man zwei ganze Zahlen einfach durch Subtraktion miteinander vergleichen kann.
Bei Indexoperationen ist das Ganze sinnvoll, wurde schon beschrieben.
Für einen Komparator braucht man nur -1, 0, 1. Hier wäre ein Enum-Wert in der Tat sinnvoller/lesbarer (dazu noch mit boolean Auswertung z.B. .isLesser(), das würde den Code sehr viel leichter lesbar machen).
Allerdings gab's die Java-Enums in dieser Form noch gar nicht, als die Comparator-Klasse definiert wurde, Enums wurden erst in Java 5 eingeführt. Ist halt noch Oldstyle-Programmierung.
Einige Komparatoren auch so umgesetzt, dass sie einen anderen Wert als -1 oder 1 liefern können. Für einen Komparator ist das zwar Overkill, für andere Operationen kann es aber schon mal sinnvoll sein. Da man sich aber nie darauf verlassen kann, was jetzt eigentlich geliefert wird und was die Werte bedeuten, kann man nur sehr spezialisiert was damit anfangen die mehr aussagen als größer oder kleiner.
Hier wäre ein Enum-Wert in der Tat sinnvoller/lesbarer (dazu noch mit boolean Auswertung z.B. .isLesser(), das würde den Code sehr viel leichter lesbar machen).
Das ist leider so nicht _ganz_ korrekt. Ein Integer.compare(x, y) kann _nicht_ durch x - y implementiert werden, aufgrund von Überlauf. Ein Integer.MIN_VALUE wäre somit nicht kleiner als 1.
Aus dem Grund ist Integer.compare(x, y) auch relativ kompliziert als return (x < y) ? -1 : ((x == y) ? 0 : 1); implementiert
Aktuell machst du eine Subtraktion, vergleichst danach, ob das Ergebnis < 0 ist.
(compareresult < 0)
(compareresult > 0)
(compareresult == 0)
Die tatsächliche Implentierung wurde oben eh schon genannt.
Würden enums verwendet, würde der Vergleich im Komparator stattfinden (anstatt der Subtraktion), extern wäre es dann so.
compareResult.wasLesser()
compareResult.wasGreater())
compareResult.wasEqual()
Ich finde das angenehmer zu lesen und zu warten, ist natürlich Geschmackssache
Und für alles andere außer Zahlen wäre es sowieso angenehmer. Lesser/Greater/Equal sind aber ziemlich mathematisch ausgedrückt. Nachdem's uns bei Komparatoren normalerweise um Sortierungen geht, wäre wohl eine andere Terminologie besser.
Nein, denn compare liefert gerade keine Konstanten sondern nur negative oder positive Zahlen bzw. die 0. Das hat den Vorteil, dass man zwei ganze Zahlen einfach durch Subtraktion miteinander vergleichen kann.
tatsächlich kam die Frage an dieser Stelle und bei der Verwendug von Rekursiven Methoden auf.
Da ist mir aber bewusst geworden, dass ich häufiger mal irgendwas habe, wo auch abgesehen davon ein return 0; auftauchte. Z.B. als letzter command in einer Methode ala
Java:
int methode () {
if (blabla){
return 200;
}
else if (blubb){
return 300;
}
// und jetzt was mich verwirrte:
return 0;
}
Aber ich denke, das hat Mihe ganz gut erörtert Ich sollte aufhören, unnötig kompliziert zu denken und mir das Leben schwer zu machen. Ich lass mich da auch schnell verunsichern wenn ich den Code von jemande lese und dann feststelle, dass ich das ganz grundsätzlich anders angegangen wäre oder vllt. auch einfach nicht direkt alles verstehe.
Ich lass mich da auch schnell verunsichern wenn ich den Code von jemande lese und dann feststelle, dass ich das ganz grundsätzlich anders angegangen wäre oder vllt. auch einfach nicht direkt alles verstehe.
Wenn Du fremden Code bekommst, ist es relativ normal, dass Du Dich erst einmal einlesen musst. Jeder hat seinen eigenen Stil, ggf. muss man sich auch erst in den Problembereich etwas einarbeiten.
Um Dein Beispiel aufzugreifen, dort sehe ich: ok, wenn blabla, dann 200, wenn blubb, dann 300 ansonsten 0. Ich weiß zwar (noch) nicht, was das soll, aber was in welchem Fall zurückgegeben wird, steht fest. Und dann muss ggf. nachgeforscht werden, um sich den Sinn von methode() zusammenreimen zu können.
Wenn dort etwas wie
Java:
int methode () {
if (blabla){
return NO_PERMISSION;
}
else if (blubb){
return NOT_AUTHENTICATED;
}
return OK;
}
gestanden hätte, hättest Du Dir nichts weiter dabei gedacht und schon eine Vorstellung davon gehabt, worum es in der Methode geht. Darum vermeidet man magic numbers (https://de.wikipedia.org/wiki/Magische_Zahl_(Informatik)). Statt der Konstanten wäre ein enum-Typ hier natürlich noch schöner.
Ich weiß zwar (noch) nicht, was das soll, aber was in welchem Fall zurückgegeben wird, steht fest. Und dann muss ggf. nachgeforscht werden, um sich den Sinn von methode() zusammenreimen zu können.
Wenn dort etwas wie
Java:
int methode () {
if (blabla){
return NO_PERMISSION;
}
else if (blubb){
return NOT_AUTHENTICATED;
}
return OK;
}
Das soll garnix, einfach ein Freestyle-Bsp. für diese Rückgabewerte, die mir Funktionslos schienen und mich verwirrten. ^^
Aber du hast nat. Recht, bei deinem Bsp wär es direkt klar.
Ich denke, er meint so was wie (15 - Integer.MIN_VALUE);
Das ist mehr als Integer.MAX_VALUE, würde also negativ sein, obwohl 15 eindeutig größer ist als Integer.MIN_VALUE.
Mit einem Zusatzbit könnte man das Problem für einen Komparator umgehen, allerdings würde das auch nicht dazu führen, dass bei der Subtraktion der korrekte Wert ausgegeben wird. Einfach einen Vergleich verwenden und gut is. Damit spart man sich den Ärger.
Lies dir duch, was ein Überlauf-Bit ist... Das ist ein Bit das gesetzt werden kann, wenn ein Über- oder Unterlauf stattfand. Java kennt solche Flags aber nicht.
@Staarfightaar, es geht um die Posts #8 und #9. Es ist richtig, dass für einen allgemeinen Integer-Vergleich die dargestellte Lösung in #8 nicht taugt. Tatsächlich vergleicht man oft aber keine beliebigen Integer-Werte, vielmehr ist der Wertebereich durch die Domäne eingeschränkt. Beispielsweise ist ein char ein vorzeichenloser 16 Bit-Wert, das Alter einer Person liegt kaum über 150 und wird selten negativ usw.
so wie ich die grundfrage verstanden habe ging es um vor "definierte methoden ergebnisse" wie compare to wo man immer ein -1 0 1 bekommt oä methoden die schon implementiert sind .. also um den grundsinn wann man sowas auspackt
so wie ich die grundfrage verstanden habe ging es um vor "definierte methoden ergebnisse" wie compare to wo man immer ein -1 0 1 bekommt oä methoden die schon implementiert sind .. also um den grundsinn wann man sowas auspackt
Genau darum ging's. Normalerweise werden Komparatoren für Sortierungen verwendet, wo es komplett wurscht ist, wie hoch der Wert ist. Deshalb kam die Idee mit der Subtraktion auf (wobei ich aber nicht glaube, dass größer/kleiner schneller oder langsamer ist als eine Subtraktion), die sich aber als fehleranfällig erweisen würde, wenn der gesamte Integer-Bereich genutzt würde.
Es gibt einzelne Komparatoren, deren Rückgabewert mehr beinhaltet als nur größer und kleiner (wenn ich mich nicht irre, gehören die compare Methoden von Strings dazu), aber die sind selten und sehr spezialisiert.
Es gibt einzelne Komparatoren, deren Rückgabewert mehr beinhaltet als nur größer und kleiner (wenn ich mich nicht irre, gehören die compare Methoden von Strings dazu), aber die sind selten und sehr spezialisiert.
