Enums zum ersten mal

[Mart]

enum Switcher{
    NEXT,PREVIOUS;
    private static LinkedList<ViewWithTopbar> list;
    private static Iterator<LinkedList<ViewWithTopbar>> iterator;
    public static final void addToList(ViewWithTopbar view) {
        list.add(view);
    }
    Switcher() {
        
    }
    public static final void switchTo(Switcher direction) {
        if(direction == Switcher.NEXT) {
            //
        }
        else if ( direction == Switcher.PREVIOUS) {
            //
        }
    }
}

also ich versuche mit dem enum das children von der Scene durchzuwechseln und dynamisch neue ansichten hinnzuzufügen nur

ich habe keinen Plan ob man die switchTo methode so benutzen sollte da ja das static nicht benutzt werden sollte ???

wie umgehe ich denn die static linked List und den Iterator

 

[kneitzel]

Also das Enum mit der Direction sehe ich ja noch, aber wie kommst Du darauf, dass die Listen da mit rein gehören würden? Was hat das mit der Direction zu tun?

Da kannst Du eine eigene Klasse machen. Von der Klasse kannst Du dann eine Instanz erzeugen und schon hast Du gar kein static mehr!

 

[Oneixee5]

Ein enum ist nicht wie eine Klasse zu handhaben, obwohl es ein paar Möglichkeiten gibt. Enum ist eher eine Aufzählung bestimmter möglicher Attribute um aus dem Konstanten-Dilemma rauszukommen.

 

[Mart]

mnja da bin ich auf dem schlauch gestanden

hab den wald vor lauter bäumen nicht gesehen, ist tatsächlich logischer das zu machen wie kneitzel es gesagt hat


ist das mit den IFs so normal oder gibts da eine bessere möglichkeit?

 

[kneitzel]

ist das mit den IFs so normal oder gibts da eine bessere möglichkeit?

Bei Enums bietet es sich auch an, ein switch zu nutzen.

 

[Oneixee5]

Switcher bietet nur 2 Möglichkeiten somit ist das else if irgendwie sinnlos:

if(direction == Switcher.NEXT) {
       
} else  {
       
}

Eine boolean.Variable würde es auch tun.

 

[Mart]

es sollten noch andere dazu kommen wie zb DEEPER da eine ViewWithTopBar mehrere ViewWithTopbars haben kann

 

[mrBrown]

ist das mit den IFs so normal oder gibts da eine bessere möglichkeit?

Enums können ganz normale Methoden haben, die für jeden Wert überschrieben werden können. Je nachdem, was man machen will, kann das sinnvoller sein.

Eine boolean.Variable würde es auch tun.

Selbst wenn es nur zwei sind ist ein Enum aber meist schon schöner, allein schon weil dann was explizites da steht und nicht nur True/False

 

[Mart]

ich werde eure ratschläge mal in code umsetzen vielen dank 😎

 

[Oneixee5]

Selbst wenn es nur zwei sind ist ein Enum aber meist schon schöner, allein schon weil dann was explizites da steht und nicht nur True/False

Ist das ein Witz?

 

[kneitzel]

Ist das ein Witz?

Nein, denn es ist eben eine Enum und kein boolean.

Und damit hat man auch 3 Möglichkeiten:
Die beiden Enum-Werte und null.

Und eine Enum kann leicht erweitert werden - und wenn man dann den neuen Wert an so einer Stelle vergisst einzupflegen, dann fällt das hinterher nicht auf. Daher ist ein default Zweig mit werfen einer RuntimeException auf jeden Fall etwas, das ich machen würde.

 

[Oneixee5]

Die beiden Enum-Werte und null.

Der TE hat keinen Zweig für null vorgesehen. Aber egal, das enum soll sowieso erweitert werden.

 

[kneitzel]

Der TE hat keinen Zweig für null vorgesehen. Aber egal, das enum soll sowieso erweitert werden.

Ja, aber das spielt keine Rolle. Er hat da halt Code, der generell sehr ... sagen wir mal seltsam ... ist. Wir können nur die generelle Vorgehensweise ansprechen. Da gibt es kein wirkliches richtig / falsch - aber halt ein Weg, den ich einschlagen würde (incl. kleiner Begründung, die ich ja versucht habe).

Und dieser Code wäre tatsächlich mit ifs bei mir eine Kette von mehreren if / else if und im letzten else das Werfen einer Exception.
Und das wären dann tatsächlich 3 Werte + die Exception. Wobei das null vermutlich schon bei der Validierung abgefrühstückt worden wäre in Form eine NPE oder so.

 

[Neumi5694]

Außerdem helfen einem die neuen Rule-Switches dabei, dass man beim späteren Hinzufügen von Werten die Auswertung derselben nicht übersieht, ohne "default" kompiliert der Code dann schlicht und einfach nicht, wenn nicht alle Fälle abgedeckt sind.
Seit der Einführung hab ich rule-switches mit Rückgabewert echt zu schätzen gelernt, warte nur noch darauf, dass "case null" freigegeben wird.

 

[Mart]

Außerdem helfen einem die neuen Rule-Switches dabei, dass man beim späteren Hinzufügen von Werten die Auswertung derselben nicht übersieht, ohne "default" kompiliert der Code dann schlicht und einfach nicht, wenn nicht alle Fälle abgedeckt sind.
Seit der Einführung hab ich rule-switches mit Rückgabewert echt zu schätzen gelernt, warte nur noch darauf, dass "case null" freigegeben wird.

mit den java 17 switches gibts case null sogar https://www.javacodegeeks.com/2021/09/java-17-pattern-matching-for-switch.html

 

[Neumi5694]

mit den java 17 switches gibts case null sogar https://www.javacodegeeks.com/2021/09/java-17-pattern-matching-for-switch.html

"preview language feature"
Ich warte noch auf die Freigabe.