char c

[catsfan]

Guten Samstagabend,

ich habe eine Verständnisfrage bezüglich eines enums.

Ich habe in einem Programm eine enumaration eingeführt mit n-beliebigen Werten, die es enthält. Nun soll diese enumeration in Verbindung mit einer char gebracht werden. Eventuell hilft folgender Beispielcode weiter?

public enum Tageszeiten{MORGEN, MITTAG, ABEND...}

Tageszeiten{char o} {
value = o;
}

Kann mir jdm. sagen, welche Rolle das char nun hier einnimmt?

 

[mihe7]

Ich verstehe die Frage nicht, aber vielleicht hilft Dir http://www.avajava.com/tutorials/lessons/how-do-i-use-the-enum-type-with-a-constructor.html weiter.

 

[Barista]

Dein Code war nicht kompilierbar, ich habe den Code für Dich korrigiert:

[CODE lang="java" title="enum Tageszeiten"]public enum Tageszeiten
{
MORGEN('o'),
MITTAG('i'),
ABEND('a');

public final char value;

Tageszeiten(char o) {
value = o;
}
}[/CODE]

Das Feld 'value' ist eine Zusatzinformation.

Weil die Enum-Ausprägungen nur einmal existieren, kann man die nicht wie normale Felder irgendwo zuweisen.

Die sind einmalig konstant.

Such mal nach Singleton.

Aber man kann Enum-Ausprägungen mit Zusatzinformationen ausstatten.

 

[Neumi5694]

In manchen Programmiersprachen entspricht ein Enum einem Char oder Int oder String. Sobald kompiliert wird, werden in den Code die entsprechenden Werte eingesetzt. Man kann den Wert also so zuweisen, wie du das gerade gemacht hast und auch umgekehrt. Man kann dort, wo ein Enum erwartet wird, z.B. einen Char übergben. In Java ist dies nicht der Fall, hier ist man vor solchen Hacks sicher.

Die Enums in Java bieten sind vollwertige eindeutige statische Objekte, bieten bei weitem mehr Möglichkeiten. Sie können allerdings in nichts anderes gecastet werden außer nach Enum und eventuell implementierte Interfaces.
Auf der anderen Seite hast du dadurch aber auch die Möglichkeit, den Enums Attribute zu geben, so wie es im Beispiel oben gemacht wurde.
Ein Enum in Java ist viel mächtiger als die simplen Char-Enums anderer Sprachen.

Solltest du mal darüber stolpern: Anders als in anderen Sprachen können Enums in Java aufgrund ihrer Natur nicht mit OR verknüpft werden.
Hierfür legst du ein EnumSet.of(...) an.

 

[Neumi5694]

Zu dem oben Erwähnten kommt noch, dass alle Attribute der Enumklasse implizit final sind.

Nein, das ist nicht richtig.
Ich verwende oft Enums für Comboxen und lass "label" als Text anzeigen. Das Attribut "label" ändere ich je nach Sprache.

Edit: ... oder meintest du die Methoden? Da würd's effektiv stimmen, da man ListEntry nicht ableiten kann.

public class TestClass {

    public static void main(String[] args) {
        ListEntry.Entry2.setLabel("NewLabel");
        System.out.println(ListEntry.Entry2.getLabel());
        //Liefert "NewLabel" als Ausgabe
    }
}

 public enum ListEntry {
     Entry1("Key1", "Defaulttext1"),
     Entry2("Key2", "Defaulttext2"),;

     private ListEntry(String key, String value) {
         this.key = key;
         this.label = value == null ? "" : value;
     }

     public String getKey() {
         return key;
     }

     public String getLabel() {
        return this.label;
     }

     public void setLabel(String label) {
        this.label = label;
     }

     private final String key;
     private String label;
}

 

[Neumi5694]

btw, ich hab vorhin den OP nicht gründlich gelesen. Meine Erläuterung zu Enums ist im Grunde hinfällig , aber vielleicht doch nützlich.

 

[kneitzel]

So Erläuterungen sind immer wieder schön, aber bei der Wortwahl sollte man bitte etwas mehr aufpassen.

Was sind "statische Objekte"?

Sie können allerdings in nichts anderes gecastet werden außer nach Enum und eventuell implementierte Interfaces.

Ja, so wie bei Klassen halt üblich: Diese können ja auch in nichts gecastet werden außer nach Klassen, von denen sie erben oder eventuell implementierte Interfaces....

Enums sind halt eine spezielle Form von Klassen und es gelten viele Regeln, die auch für die Klassen selbst gelten.

Und da kann man in der JLS auf sehr kompakte Art und Weise alles Wichtige erfassen und sehen: https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.9

An enum declaration specifies a new enum class, a restricted kind of class that defines a small set of named class instances.

It is a compile-time error if an enum declaration has the modifier abstract or final.

An enum class is implicitly final unless its declaration contains at least one enum constant that has a class body (§8.9.1).

A nested enum class is implicitly static. That is, every member enum class and local enum class is static. It is permitted for the declaration of a member enum class to redundantly specify the static modifier, but it is not permitted for the declaration of a local enum class (§14.3).

It is a compile-time error if the same keyword appears more than once as a modifier for an enum declaration, or if an enum declaration has more than one of the access modifiers public, protected, and private (§6.6).

The direct superclass type of an enum class E is Enum<E> (§8.1.4).

An enum declaration does not have an extends clause, so it is not possible to explicitly declare a direct superclass type, even Enum<E>.

An enum class has no instances other than those defined by its enum constants. It is a compile-time error to attempt to explicitly instantiate an enum class (§15.9.1).

Ok das stimmt. streichen

Ich würde es nicht streichen sondern eher als Best Practice umformulieren. So eine Nutzung wie von @Neumi5694 gezeigt ist technisch zwar möglich aber habe da eher Bedenken (Wobei ich den genauen Usecase jetzt nicht erfasst habe und daher nicht urteilen kann und will, ob es Sinn macht)

 

[Neumi5694]

Was sind "statische Objekte"?

Singletons wäre wohl der bessere Ausdruck, hab's halt versucht, einfach auszudrücken. Die Ausdrucksweise darf gerne verbessert werden.

Enums

www.straub.as

Meine Erwähnung der Casts bezog sich darauf, dass Enums in einigen anderen Sprachen sehr wohl in andere Typen gecastet werden können, in Java aber eben nicht. Und - wie gesagt - ich hatte den OP nicht richtig gelesen. Das Thema hat sich also eh erübrigt.

Ich würde es nicht streichen sondern eher als Best Practice umformulieren. So eine Nutzung wie von @Neumi5694 gezeigt ist technisch zwar möglich aber habe da eher Bedenken (Wobei ich den genauen Usecase jetzt nicht erfasst habe und daher nicht urteilen kann und will, ob es Sinn macht)

Nichts "macht" jemals einen Sinn.
Bisher hab noch keinen Hinweis darauf gefunden, dass die "Best Practice" empfiehlt, änderbare Eigenschaften von Enums zu vermeiden. Ich würde "Best Practice" durch "Persönliche Präferenz" ersetzen.

In meinem Fall hat sich's als die praktischste Methode erwiesen.
Egal, wo die Werte zur Auswahl stehen (und das sind eine Menge Formulare), brauch ich keine Renderer und ähnliches zu schreiben (die toString() Methode liefert bei diesen Werten den anzuzeigenden Text). Wenn schon nichts anderes, dann spart spart es doch unzählige unnötige Map-Zugriffe.

 

[kneitzel]

Nichts "macht" jemals einen Sinn.

Die Wortwahl war so vielleicht nicht besonders gut, da nicht wirklich festgelegt ist, wann Code "Sinn macht". Da wird man bestimmt einiges definieren können wie Funktionalität, Clean Code u.s.w. Aber das werden dann Dinge sein, die sich mit der Zeit verändern und das macht dann "sinnvollen Code" mit der Zeit zu "legacy Code". Also ja - Wortwahl war nicht gut.

In meinem Fall hat sich's als die praktischste Methode erwiesen.
Egal, wo die Werte zur Auswahl stehen (und das sind eine Menge Formulare), brauch ich keine Renderer und ähnliches zu schreiben (die toString() Methode liefert bei diesen Werten den anzuzeigenden Text).
Man könnte natürlich auch eine Map hinterlegen und die Renderer entsprechend schreiben, aber diese Methode hat sich als praktischer erwiesen.
Einmalig wird für alle Objekte egal welcher Klass, die einen Key und einen anzuzeigenden Text haben, eben jener gesetzt und steht dann überall zur Verfügung.

Hier habe ich evtl. auch nicht gut genug formuliert. Generell finde ich neue Ansätze immer interessant. Eine Bewertung deines Codes ist nur mit deutlich mehr Details möglich ... und dann auch nur mit konkretem Code. Auf den ersten Blick hört es sich etwas so an, als ob da die Ansätze bezüglich Localization in Frage kommen könnten. Aber so Dinge wirst Du bestimmt auch mit überlegt haben.
Und dann muss auch klar sein: es gibt ja nicht eine richtige Lösung und andere Lösungen sind falsch.

Und ich bin ein Gegner von diesen "Pattern". Das kann man so bringen aber dann mit Argumenten. Und dann kann man immer im konkreten Fall überlegen: Ziehen die Argumente oder laufen die im konkreten Fall ins Leere?

Daher auf jeden Fall Danke noch einmal für die kurze Erläuterung. Und schade, dass man kein Code Review machen kann - denn interessant wäre Deine Nutzung auf jeden Fall

 

[Barista]

Bisher hab noch keinen Hinweis darauf gefunden, dass die "Best Practice" empfiehlt, änderbare Eigenschaften von Enums zu vermeiden. Ich würde "Best Practice" durch "Persönliche Präferenz" ersetzen.

Wenn Du allein arbeitest, ist es ok, wie alles.

In einem Team, vor allem mit wechselnden Mitgliedern, wäre es sicher eine böse Überraschung.

 

[Neumi5694]

Wenn Du allein arbeitest, ist es ok, wie alles.

In einem Team, vor allem mit wechselnden Mitgliedern, wäre es sicher eine böse Überraschung.

Ich bin mir sicher, dass meine Mitarbeiter in der Lage sind, Dokumentation zu lesen.
Das Schlimmste, was jemand hier verbocken kann, ist, dass anstatt des übersetzten Texts der Key angezeigt wird.

@kneitzel
Da ist eigentlich gar nicht so viel dahinter. Geschützten Code darf ich hier natürlich nicht posten. Aber grundsätzlich schaut ein Enum aus wie oben, überschreibt zusätzlich noch die toString-Methode und implementiert ein Interface mit den Methoden getLabelKey(), getLabel() und setLabel(String).
Die Enum-Werte selbst sind Einstellungen wie "Bearbeitungskorrektur mittig/rechtskorrigiert/linkskorrigiert/nach außen korrigiert/nach innen korrigiert" oder verschiede Optimierungseinstellungen für die Produktionslogik. Anstatt in Comboboxen und Listen mit einer Kombination aus Anzeigetext + Key zu arbeiten (das hatte ich ursprünglich vor der Verwendung der Enums) und dann jeweils die passende Einstellung zu ermitteln, werden direkt die Enum-Werte für das Modell verwendet, die toString-Methode liefert die anzuzeigenden Texte.
In einer Hilfsklasse sind alle mehrsprachig anzuzeigenden Enum-Klassen (also die, die das Interface implementieren) registriert, beim Sprachwechsel (bzw. Programmstart) werden die anzuzeigenden Texte einmalig ausgelesen und zugewiesen.
Der Vorteil ist eben, dass alles zentralisiert verwaltet wird, in den Formularen und OnScreen-Logs selbst muss für die Anzeige der Optionen nichts mehr gemacht werden.

 

[Barista]

Es gibt Manche, die lieben den Rahmen und die Infrastruktur, welche Java-Enums bieten.

2015 war ich in einem Projekt, in dem Such-Formulare als Enums codiert wurden.
Jedes Such-Kriterium war eine Enum-Ausprägung.

2016/17 war ich in einem Projekt, welches einen eigenen ORM-Mapper hatte, in dem jedes Feld eine Enum-Ausprägung war, die enum-Klasse stand für eine Tabelle.

Ich persönlich finde den angebotenen Rahmen (Einschränkung) und die Infrastruktur, die der Java-Compiler bietet, nicht so entscheidend.

Das bisschen kann man sich auch generieren und man hat nicht die Einschränkung auf eine Dimension, alle Enum-Ausprägungen eines Enums sind Objekte einer Klasse, keine Views (Einschränkungen) oder Erweiterungen usw. (ich hatte mal einen Chef, der sagte, usw. bedeutet "ich weiss nichts mehr", mir würden aber wirklich noch Sachen einfallen).

Aber wem es gefällt, ok.

 

[mrBrown]

Bisher hab noch keinen Hinweis darauf gefunden, dass die "Best Practice" empfiehlt, änderbare Eigenschaften von Enums zu vermeiden. Ich würde "Best Practice" durch "Persönliche Präferenz" ersetzen.

Die beiden Dinge, die dagegen sprechen, sind einmal das übliche "statische Dinge sollten nicht veränderlich sein"* und dann, dass es völlig entgegen der Erwartung fast jedes Nutzers ist.

* Ist natürlich nicht statisch, aber die Regel würde ich überwiegen auch für Enums und deren direkte Eigenschaften gelten lassen.


Als weiteren Nachteil davon würde ich die Vermischung von Model und View sehen – entweder das ist Teil des Models, dann hätten Label darin nichts zu suche, oder es ist Teil der View, dann dürfte man es nicht im Model nutzen.

 

[Neumi5694]

[...]die Vermischung von Model und View[...]

Grundsätzlich stimme ich da vollkommen zu, es handelt sich um einen sehr speziellen Fall, dafür gedacht, möglichst wenig verteilten redundanten Code zu haben.