Objektvergleich Enum

[elsamuray7]

Ich habe ein Objekt status einer Klasse PlayerSate, die ein enum mit den Zuständen NO_FILE. PLAYING, PAUSED und STOPPED ist. status nimmt immer jeweils einen dieser Zustände an.
Wenn ich jetzt in einem if-Statement überprüfen will ob status im Moment den Zustand PLAYING hat, muss ich dann...
a) if (this.status.equals(PlayerState.PLAYING)) oder
b) if (this.status == PlayerState.PLAYING) schreiben?
Bzw.: Muss ich ich auf Gleichheit oder "Selbstheit" überprüfen?

 

[Tarrew]

Die equals Methode in der Klasse Enum ist so implementiert:

/**
* Returns true if the specified object is equal to this
* enum constant.
*
* @param other the object to be compared for equality with this object.
* @return  true if the specified object is equal to this
*          enum constant.
*/
public final boolean equals(Object other) {
    return this==other;
}

Also wird intern auch nur mit == verglichen. Würde trotzdem direkt mit == arbeiten anstatt mit equals, dann vermeidest du eine potentielle NullPointerException.

 

[Tobse]

Von einem Enum-Eintrag gibt es nur eine Instanz. == ist bei Enums also immer Korrekt. Equals würde ich da nur verwenden, wenn wirklich komplexe Logik mit im Spiel ist.

 

[stg]

Equals würde ich da nur verwenden, wenn wirklich komplexe Logik mit im Spiel ist.

Man weiß aber ja nie, ob die equals-Methode nicht doch überschrieben wurde, oder es später mal wird. Ich würde den Vergleich mit equals immer vorziehen.

Würde trotzdem direkt mit == arbeiten anstatt mit equals, dann vermeidest du eine potentielle NullPointerException.

Die vermeidet man auch, wenn man die Überprüfung umdreht. Also einfach PLAYING.equals(status) anstatt status.equals(PLAYING)

Siehe auch: http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#equals-java.lang.Object-

 

[InfectedBytes]

Die equals Methode von Enum ist final und kann daher gar nicht überschrieben werden. Dementsprechend ist bei enums == vorzuziehen.

 

[stg]

Da hast du natürlich recht... Man könnte jetzt natürlich an den Haaren herbeigezogen argumentieren, dass man sich dann darauf verlässt, dass PlayerState auch in Zukunft als enum implementiert wird, aber lassen wir das

Als Grund für den Vergleich mit == würde ich dann schon eher sehen, dass man bereits beim Compilen eine Typ-Überprüung hat und Fehler hier somit schneller bemerkt werden können.

 

[Jardcore]

Ich würde dafür ein wenig Clean Code anwenden und extra Methoden im Enum implementieren.

public boolean isPlaying() {
    return this == PLAYING;
}

public boolean isPaused() {
    return this == PAUSED;
}

public boolean isStopped() {
    return this == STOPPED;
}

Ich weiß nicht genau was NO_FILE mit einem PlayerState zutun hat, würde hier überlegen ob das wirklich korrekt ist.

Die Abfragen ist dann schön leserlich

if(status.isPlaying()) {
   //...
}

Du kannst allerding auch einfach ein Switch benutzen:

switch(status) {
    case PLAYING:
    break;
    case PAUSED:
    break;
    case STOPPED:
    break;
}

 

[Tobse]

public boolean isPlaying() {
    return this == PLAYING;
}

public boolean isPaused() {
    return this == PAUSED;
}

public boolean isStopped() {
    return this == STOPPED;
}

Ich weiß nicht genau was NO_FILE mit einem PlayerState zutun hat, würde hier überlegen ob das wirklich korrekt ist.

Die Abfragen ist dann schön leserlich

if(status.isPlaying()) {
   //...
}

Diese Methode würde ich, wann immer Möglich, bevorzugen. Seinen Code mit switch()es vollzustopfen ist der Tod für Polymorphie+OO und kommt hart auf einen uurück, wenn später ein weiterer Enum-Eintrag hinzukommt.