enum Fruit {
APPLE, BANANA, ORANGE
}
vs
enum Fruit {
Apple, Banana, Orange
}
ersteres entspricht den offiziellen Java Standards, da enums Konstanten sind, man aber desoefteren sieht, dass die mehr natürliche Schreibweise als variable gespeichert wird um dann toString() etc zu überschreiben.
Welche Variante nehmt ihr ?
Banana definieren, aber toString() überschreiben damit dann trotzdem „BANANA“ ausgegeben wird?
wohl eher nicht, wenn so eine Ausgabe gewünscht ist, dann würde ich auch den Enum-Wert BANANA nennen
meist geht Enum-Wert Banana und Ausgabe „Banana“ Hand in Hand,
bzw. dieses automatische toString() ist mit ein Grund dafür, den Wert lieber gleich normal zu schreiben
edit:
gemeint war mit dem Zitat also BANANA(„Banana“) + toString(),
tja, wie sonst wenn man ordentlichen Text will aber sich an die Großschreibregel hält
edit:
für Auswahlmöglichkeit „PascalCase“ wären Beispiele mit entspechenden Wörtern besser, überhaupt dann die Frage der Trennung
BANANA_SPLIT oder BananaSplit, toString() dann aber öfter unumgänglich für Leerzeichen usw., „Banana split“
Ich nutze Enum-Konstanten die einen privaten Konstruktor aufrufen. In dem Konstruktor gibt es neben der Id auch noch einen Anzeigennamen um ein ordentliches “toString” zu erhalten.
public enum SapSeverity {
NONE(0, "none"),
FATAL(1, "fatal"),
ERROR(2, "error"),
WARNING(3, "warning"),
INFO(4, "info"),
PATH(5, "path"),
DEBUG(6, "debug"), ;
public static final int LOWEST_ID = 1;
public static final int HIGHEST_ID = 6;
private final int id;
private final String displayName;
private SapSeverity(int id, String displayName) {
this.id = id;
this.displayName = displayName;
}
public static SapSeverity getById(int id) {
for (SapSeverity value : values()) {
if (value.getId() == id) {
return value;
}
}
return NONE;
}
public static SapSeverity getByDisplayName(String displayName) {
for (SapSeverity value : values()) {
if (displayName.equals(value.getDisplayName())) {
return value;
}
}
return NONE;
}
public int getId() {
return id;
}
public String getDisplayName() {
return displayName;
}
public int getOrdinal() {
return ordinal();
}
public boolean logsMoreThan(SapSeverity other) {
boolean result = false;
if (other != null && id > other.getId()) {
result = true;
}
return result;
}
public boolean logsLessThan(SapSeverity other) {
boolean result = false;
if (other != null && id < other.getId()) {
result = true;
}
return result;
}
public boolean hasAMoreCriticalLevelThan(SapSeverity other) {
boolean result = false;
if (id >= LOWEST_ID && id < other.getId()) {
result = true;
}
return result;
}
public boolean hasALessCriticalLevelThan(SapSeverity other) {
boolean result = false;
if (id > other.getId()) {
result = true;
}
return result;
}
}
[QUOTE=Falk]Ich nutze Enum-Konstanten die einen privaten Konstruktor aufrufen. In dem Konstruktor gibt es neben der Id auch noch einen Anzeigennamen um ein ordentliches “toString” zu erhalten.
[/quote]
aufsteigende id kann auch über ordinal() geregelt werden, wenns passt.
Ansonsten ist das hier ein gutes Bsp - warum “NONE” definieren und dann “none” übergeben - warum nicht “none” als enum definieren ?
[QUOTE=SlaterB;134540]Banana definieren, aber toString() überschreiben damit dann trotzdem “BANANA” ausgegeben wird?
wohl eher nicht, wenn so eine Ausgabe gewünscht ist, dann würde ich auch den Enum-Wert BANANA nennen[/QUOTE]
mir gehts darum dass es offiziell heisst man soll “BANANA” schreiben, und man dann “Banana” dort speichert, um toString zu überschreiben
Ich halte es so wie @Falk . Falls ich eine ID benötige, übergebe ich sie explizit - ordinal ist grundsätzlich nicht zu verwenden, es sei denn für Implementierungen einer EnumMap o. ä…
Wenn ich eine andere Ausgabe in toString haben möchte, übergebe ich den Wert auch im Konstruktor.
Der “Vorteil” ist, dass der Enum-Wert im Quellcode direkt als solcher erkennbar ist.
ganz klein schreiben schickt sich nun gar nicht, ist den Variablen vorbehalten, auch wenn Enum meist trotzdem erkennbar wäre
nur ein Großbuchstabe bzw. PascalCase/ CamelCase ist Mittelweg gegenüber anderen statischen KONSTANTEN,
zur Unterscheidung von diesen durchaus auch wieder ein guter Weg, Verwechslung mit Klasen kommt nicht vor,
das passt einfach, Enum ist auch ein großer und für sich wichtiger Bereich, erlaubt etwa ==-Vergleich, schade dass nicht auch <, > usw.,
der eigene Benennungsklasse rechtfertigt:
static final: BANANE
Enum: Banane
sonstige Variablen: banane
Anmerkung:
Das “NONE” sollte vielleicht besser “UNDEFINED” heiszen weil durch die statischen Suchmethoden eventuell nichts gefunden werden kann.
Oder was meinst Du @bygones ?
nur die Schreibweise der Benennung steht in Frage (NONE vs None vs none vs …), + evtl. Übergabe für toString() bzw. hier getDisplayName() usw.,
keine fachliche Bedeutung angesprochen in der Hauptfrage des Themas
Die toString()-Methode wird bei Enums (hoffentlich) nur zu debug-/log-Zwecken eingesetzt, und da spielt es doch keine Rolle, ob da banana, Banana, oder BANANA steht.
Wenn der Wert aber bspw. in der UI angezeigt wird, sollte eine ordentliche I18N her (zumindest die Variante mit einem privaten String-Konstruktor). Ansonsten besteht die Gefahr, dass jemand der Meinung ist, ein Enum umbenennen zu müssen, ohne dass ihm die Auswirkung bewusst ist. Oder andersrum - jemand muss ein Enum nur deswegen umbenennen, weil er den Anzeigewert ändern will - da sollten IMHO nicht gleich x Klassen verändert werden.
Ich halte mich an die Java Conventions, also UPPERCASE.