Setter-und-Getter-Konvention

[Hutmacher]

Wenn man immer Setter- und Gettermethoden machen soll, warum macht das dann oft Sun selbst nicht?
Z.B. heißt bei String die Methode zum getten der Länge nicht
String#getLength(), sondern String#length(). Oder bei Object die Methode hashCode() anstatt getHashCode().

Warum?

 

[Marco13]

Teilweise können solche Sachen "Altlasten" sein, teilweise hängt es auch damit zusammen, dass dort nichts geGETet wird: HashCode rechnet etwas aus - i.a. bei jedem Aufruf neu. Es gibt keine private Variable "hashCode", auf die man mit "get" zugreifen würde.

 

[Hutmacher]

wieso schreibt man dann nicht nach der methodennamenkonvention z.b. calculateHashCode()?

(kleinschreibung, da mit psp on)

 

[Noctarius]

hashing ist schon ein Verb, vermutlich deswegen. Hashen ist eine definierte Berechnung. hasCode steht dann quasi für hashToCode.

 

[Marco13]

Naja - DAS klingt jetzt IMHO schon ein bißchen weit hergeholt... Aber es gibt eben hin und wieder kleinere ... Unstimmigkeiten, vor allem in den älteren Klassen... und "Object".. joa...

 

[musiKk]

Ich plädiere auch teilweise für Altlasten. Vor allem bei Größenangaben wird das laufend anders gemacht. Bei Strings ist es length(), bei Collections size(), bei NodeList getLength() und getSize() gibs sicher auch. Ohne IDE mit Autovervollständigung macht sowas keinen Spaß.
Andererseits werden die Getter/Setter vor allem für private Variablen in Objekten verwendet und bei hashCode oder der Länge eines Strings handelt es sich um Eigenschaften/Berechnungen.

 

[Noctarius]

Mit dem Zusatz, dass bei immutable Objects wie z.B. String der Hashcode genau einmal berechnet wird (bei Conncurrency eventuell mehrmals aber immer mit dem selbem Berechnungsergebnis) und sobald ein Wert bekannt ist wird nicht mehr gerechnet sondern nur noch zurückgegeben.

public PseudoString {
    private Integer hashCode = null;

    public int hashCode() {
        // Hier braucht nicht synchronisiert werden, da das Ergebnis der
        // Berechnung immer das Selbe ergibt. Voraussetzung: Objekt ist immutable
        if (hashCode == null)
            hashCode = hashCodeInterneBerechnung();

        return hashCode.intValue();
    }
}

 

[Spacerat]

Sind Konventionen etwa in Stein gemeisselt? Doch wohl eher in Schnee gepin... Einer kann doch auch so eine Art "hashCode"-Methode mit "erzaelMirEinVomPferd()" benennen, auch wenn es keinen Sinn macht.
Die Konventionen für "getter" setzen im übrigen Werte voraus, welche über "setter" gesetzt werden bzw. werden könnten. Ein Hashcode oder eine Zeichenkettenlänge gehören nicht dazu und Suns Methoden sind deswegen auch heute noch, so wie sie sind, durchaus sinnvoll bezeichnet.

 

[maki]

Sind Konventionen etwa in Stein gemeisselt?

Diese Konventionen stehen in der JavaBEan Spek