Mehrfache if-else-Abfrage zusammenfassen

[Gelöschtes Mitglied 82461]

Guten Abend,
Wie im Titel bereits beschrieben geht meine Frage um das Zusammenfassen von mehrfachen if-else-Abfragen.
Als Programmierumgebung benutzte ich XDEV 6, die Frage bezieht sich allerdings ganz allgemein auf die Programmierung (auch nicht nur Java) und nicht auf XDEV.

Also...
Ich bin gerade dabei mir mittels XDEV eine GUI zu programmieren, in welcher man unter Anderem eine Combobox zur Auswahl hat. Diese Combobox ändert ihren Index mit der Auswahl eines Eintrages. Heißt Ich habe zum Beispiel die Auswahlmöglichkeiten Hund, Katze und Maus. Hund hat den Index 0, Katzte den Index 1 und Maus den Index 2.
Nun frage ich per if-else den Index ab und öffne dadurch dann ein Fenster in einem windowContainer. Bei meinen 6 Auswahlmöglichkeiten wird es allerdings etwas unübersichtlich.
Jetzt meine Frage, ob man das irgendwie zusammenfassen kann (ich stelle mir das ungefähr so wie in der angehängten Datei vor)?

Würde mich über jeden Lösungsansatz freuen auch wenn er vielleicht etwas albern erscheint und hoffe ihr habt meine Frage verstanden 😉
Liebe Grüße
Benjamin



HIER MEIN CODE:

@EventHandlerDelegate
    void comboBox_itemStateChanged(ItemEvent arg0)
    {
        int selectionComboBox = comboBox.getSelectedIndex();
        
        if(selectionComboBox == 0)
        {
            windowContainer.setXdevWindow(new wndNdG());
        }
        else
        {
            if(selectionComboBox == 1)
            {
                windowContainer.setXdevWindow(new wndNdM());
            }
            else
            {
                if(selectionComboBox == 2)
                {
                    windowContainer.setXdevWindow(new wndNdParameter());
                }
                else
                {
                    if(selectionComboBox == 3)
                    {
                        windowContainer.setXdevWindow(new wndNdAlarm());
                    }
                    else
                    {
                        if(selectionComboBox == 4)
                        {
                            windowContainer.setXdevWindow(new wndNdError());
                        }
                        else
                        {
                            windowContainer.setXdevWindow(new wndNdOther());
                        }
                        
                    }
                    
                }
            }
        }
    }

 

[KonradN]

a) Wenn Du if / else if / else if / else Konstrukte hast, dann mach beim else if keinen Block. Dann hast Du nicht diese immer tiefere Einrückung.

b) Wenn du bei einer Variable mehrere Werte abfragen willst, dann kannst Du den switch Befehl nutzen.

 

[KonradN]

Ach ja - falls ein switch nicht möglich ist, weil es z.B. nicht um int Werte sondern um Instanzen geht oder so, dann kannst Du auch eine Map verwenden, die Du füllst.

Dann hast Du eine Map mit den Instanzen als Key und Value ist dann eine Methodenreferenz oder so. Also in der Regel etwas aus dem java.util.function Namespace oder ein funktionales Interface.

 

[Gelöschtes Mitglied 82461]

Hi Konrad,
Erstmal vielen Dank für deine Hilfe!!!
Habe es mit der switch-Methode gelöst und bin sehr zufrieden.

Vielen Dank nochmal und noch einen schönen Abend
Benjamin

PS:
Um anderen den Aufbau einer solchen Methode zu zeigen hier der neue Code:

    @EventHandlerDelegate
    void comboBox_itemStateChanged(ItemEvent arg0)
    {
        int selectionComboBox = comboBox.getSelectedIndex();
        
        switch(selectionComboBox)
        {
            
            case 1:
            {
                windowContainer.setXdevWindow(new wndNdM());
            }
            break;
            case 2:
            {
                windowContainer.setXdevWindow(new wndNdParameter());
            }
            break;
            case 3:
            {
                windowContainer.setXdevWindow(new wndNdAlarm());
            }
            break;
            case 4:
            {
                windowContainer.setXdevWindow(new wndNdError());
            }
            break;
            case 5:
            {
                windowContainer.setXdevWindow(new wndNdOther());
            }
            break;
        
            default:
            {
                windowContainer.setXdevWindow(new wndNdG());
            }
        }
        
    }

 

[KonradN]

Die Blöcke im case sind eher unüblich. Die mehr übliche Formatierung wäre dann:

    @EventHandlerDelegate
    void comboBox_itemStateChanged(ItemEvent arg0) {
        int selectionComboBox = comboBox.getSelectedIndex();
       
        switch(selectionComboBox) {
           
            case 1:
                windowContainer.setXdevWindow(new wndNdM());
                break;

            case 2:
                windowContainer.setXdevWindow(new wndNdParameter());
                break;
               
            case 3:
                windowContainer.setXdevWindow(new wndNdAlarm());
                break;
               
            case 4:
                windowContainer.setXdevWindow(new wndNdError());
                break;
               
            case 5:
                windowContainer.setXdevWindow(new wndNdOther());
                break;
       
            default:
                windowContainer.setXdevWindow(new wndNdG());
        }      
    }

Edit: In Java ist es üblich, die öffnenden Klammern am Ende der Zeile zu haben.

 

[Gelöschtes Mitglied 82461]

Noch besser. Ich dachte nur dass das so gehört, da es wo ich die "Schreibweise" nachgelesen habe so dargestellt wird.
Aber wenn die Klammern nicht zwingend notwendig sind soll's mir sehr recht sein.

Vielen Dank für den Hinweis

 

[philanthrop]

Man kann innere Blöcke verwenden. Aber muss man nicht. Falls man sie verwendet, ist es übersichtlicher, die break; Anweisung mit in diese Blöcke zu schreiben.

 

[mihe7]

Mit neueren Java-Versionen:

        windowContainer.setXdevWindow(switch (selectionComboBox) {
            case 1 -> new wndNdM();
            case 2 -> new wndNdParameter();
            case 3 -> new wndNdAlarm();
            case 4 -> new wndNdError();
            case 5 -> new wndNdOther();
            default -> new wndNdG();
        });

 

[philanthrop]

Hier noch schnell der Generics Flavor (damit kann man sich die Fallunterscheidung(switch-case) sparen):

import java.lang.reflect.InvocationTargetException;
import java.util.HashMap;

public class EncapsulateInstantiation {
    public static class MyClassA {
        public MyClassA() {
            System.out.println("MyClassA was instantiated.");
        }
    }

    public static class MyClassB {
        public MyClassB() {
            System.out.println("MyClassB was instantiated.");
        }
    }

    public static class MyClassC {
        public MyClassC() {
            System.out.println("MyClassC was instantiated.");
        }
    }

    @SuppressWarnings("unchecked")
    public static <T> T getInstance(final Class<T> type) throws InvocationTargetException, InstantiationException, IllegalAccessException {
        HashMap<String, Class<?>> map = new HashMap<>();
        map.put(MyClassA.class.getName(), MyClassA.class);
        map.put(MyClassB.class.getName(), MyClassB.class);
        map.put(MyClassC.class.getName(), MyClassC.class);

        Class<?> aClass = map.get(type.getName());
        if (aClass == null) {
            return null;
        }
        return (T) aClass.getConstructors()[0].newInstance(new Object[0]);
    }

    public static void main(final String[] args) throws InvocationTargetException, InstantiationException, IllegalAccessException {
        MyClassB myb = getInstance(MyClassB.class);
    }
}

( anstatt Class<T> type könnte man dann einen int-Wert übergeben )

 

[philanthrop]

Also sprich so:

    @SuppressWarnings("unchecked")
    public static <T> T getInstance(final int type) throws InvocationTargetException, InstantiationException, IllegalAccessException {
        HashMap<Integer, Class<?>> map = new HashMap<>();
        map.put(1, MyClassA.class);
        map.put(2, MyClassB.class);
        map.put(3, MyClassC.class);

        Class<?> aClass = map.get(type);
        if (aClass == null) {
            return null;
        }
        return (T) aClass.getConstructors()[0].newInstance(new Object[0]);
    }

    public static void main(final String[] args) throws InvocationTargetException, InstantiationException, IllegalAccessException {
        MyClassB myb = getInstance(2);
    }

Das @SuppressWarnings("unchecked") kommt durch den Cast in der return Anweisung ... Falls man das nicht möchte, sollte man Object bzw. einen Superklassentyp zurückgeben.

 

[thecain]

Statt dem ganzen Reflection könnte auch einfach eine Supplier Funktion in die Map eingefügt werden. Also

map.put(1, MyClassA::new);

 

[philanthrop]

Danke für die Ergänzung. Ich wusste nicht dass das möglich ist (bei Konstruktor).

 

[KonradN]

Das mit der Map ist der Weg, den ich in #3 erwähnt hatte. Auch ohne die Methodenreferenz auf den Konstruktor wäre es denkbar, dass über eine Lambda Expression zu machen. Der Ausdruck von @thecain wäre dann z.B, ein map.put(1, () -> new MyClassA());

Und bei dem Code in #9 macht das wenig Sinn:

        HashMap<String, Class<?>> map = new HashMap<>();
        map.put(MyClassA.class.getName(), MyClassA.class);
        map.put(MyClassB.class.getName(), MyClassB.class);
        map.put(MyClassC.class.getName(), MyClassC.class);

        Class<?> aClass = map.get(type.getName());

Du hast in type bereits die Class<T>. Daher musst Du da nicht erst den Namen holen um dann die Class erneut zu bekommen. Etwas in der Art wäre nur dann sinnvoll, wenn Du da Abweichungen hättest a.la. "List" -> ArrayList.class oder so. Aber da macht dann das Generic keinen Sinn. Ebenso ist bei dem Code mit dem int Wert der Generic nicht wirklich sinnvoll in meinen Augen.

Aber die Map Lösung ist immer dann sinnvoll, wenn ein switch nicht geht (Weil der Typ nicht unterstützt wird oder weil es dynamisch ist und nicht alle Fälle bekannt sind).

Und natürlich steht dann noch die Frage im Raum, was denn da als Typ angegeben wird für den Value der Map. Da kann man dann zum einen bei den vorhandenen Elementen von java.util.function schauen - da wäre dann z.B. Supplier<T> das mit der T get(); Methode ein passendes funktionales Interface ist.
Ansonsten geht jedes funktionales Interface mit entsprechender Methodensignatur. Wenn einem das get() also nicht passt, dann kann man auch etwas bauen wie:

public interface Factory<T> {
    T create();
}

Dann hat man halt speziell für die Map einen eigenen Typ und es wird dann auch klar bei der Nutzung, denn man hat dann etwas wie: map.get(....).create(); und es wird deutlich, dass eine neue Instanz erzeugt wird und nicht einfach nur eine Instanz zurück gegeben wird. Bei einem get() ist eher die Erwartungshaltung, dass zwei get() Aufrufe hintereinander immer das selbe zurück gibt. Das würde aus meiner Sicht etwas dagegen sprechen.

 

[philanthrop]

War nur ein Beispiel. #10 ist als Korrektur zu #9 zu verstehen ... Aber wenn du nur public static <T> T getInstance() (bzw. public static <T> T getNewInstance()) hast, dann kommst du nicht an den Typ / an getClass() des Typs heran.

Ob die Methode nun get... oder new... heißt ist fast egal ... Instance deutet an, dass es hier um eine Instanziierung geht. Ich würde getNewInstance fast als doppelt gemoppelt empfinden.

Wie dem auch sei, ...::new ist deutlich angenehmer zu lesen. Es ist aber noch fraglich, ob das auch für alle Fälle funktionieren würde.

Solche Konstrukte hat man relativ selten. Ad hoc fiele mir gar kein (sinnvolles) Anwendungsbeispiel ein.

Das mit der Map ist der Weg, den ich in #3 erwähnt hatte.

Stimmt, da hatte ich halb überlesen, aber ein Beispiel dazu gebracht.

 

[philanthrop]

Ich hab mal gerade etwas damit herumgespielt ... Es ist doch in allen Fällen möglich, aber es ist teils "abartig", was alles geht:

import java.util.HashMap;
import java.util.function.Function;
import java.util.function.Supplier;

public class EncapsulateInstantiation {
    public static class MyClassA {
        public MyClassA() {
            System.out.println("MyClassA was instantiated.");
        }
    }

    public static class MyClassB {
        public MyClassB() {
            System.out.println("MyClassB was instantiated.");
        }

        public MyClassB(final String s) {
            System.out.println(s);
        }
    }

    public static class MyClassC {
        public MyClassC() {
            System.out.println("MyClassC was instantiated.");
        }
    }

    @SuppressWarnings("unchecked")
    public static <T> T getInstance(final int type, final String dummyString) {
        HashMap<Integer, Supplier<?>> supplierHashMap = new HashMap<>();
        supplierHashMap.put(1, MyClassA::new);
        supplierHashMap.put(2, MyClassB::new);
        supplierHashMap.put(3, MyClassC::new);
        HashMap<Integer, Function<?, ?>> functionHashMap = new HashMap<>();
        functionHashMap.put(4, (Function<String, MyClassB>) MyClassB::new);

        if (type >= 1 && type <= 3) {
            return (T) supplierHashMap.get(type).get();
        } else if (type == 4) {
            return (T) ((Function<String, ?>) functionHashMap.get(type)).apply(dummyString);
        } else {
            return null;
        }
    }

    public static void main(final String[] args) {
        MyClassB myb = getInstance(2, "dummy1");
        System.out.println("myb = " + myb);
        MyClassB myb2 = getInstance(4, "dummy2");
        System.out.println("myb2 = " + myb2);

    }
}

die Ausgabe ist dann tatsächlich:

MyClassB was instantiated.
myb = EncapsulateInstantiation$MyClassB@5674cd4d
dummy2
myb2 = EncapsulateInstantiation$MyClassB@63961c42

 

[Gelöschtes Mitglied 82461]

Vielen vielen Dank erstmal für eure rege Beteiligung!!!
Aufgrund meiner erst als Grundlagen existierenden Java-Fähigkeiten benutzte ich jetzt die switch-case Methode, da #8 bei mir nicht funktioniert ( "->" wird rot unterstrichen und er scheibt "Syntax error on token "->", : expected" ... soll ich einen Doppelpunkt irgendwo einfügen?) und ich das mit der HashMap nicht verstanden habe. Ist diese insgesamt nicht etwas zu "schlau" für meine Aufgabe? Und dann etwas viel länger als switch-case?

 

[philanthrop]

Welche Java-Version verwendest du? (JDK)

 

[philanthrop]

Ist diese insgesamt nicht etwas zu "schlau" für meine Aufgabe? Und dann etwas viel länger als switch-case?

Eine Fallunterscheidung benötigt immer eine gewisse Zeit... Bei 5 Fällen ist das absolut vernachlässigbar (und sogar schneller ), aber wenn es jetzt 5 Millionen Fälle gäbe, dann ist eine "dynamische" Herangehensweise besser.

Das bedeutet, mach dir um die map-Sachen erst einmal noch keinen Kopf ...

 

[Gelöschtes Mitglied 82461]

Okay, Danke.
Installiert sind die jre-1.8 und jdk-20. Benutzten tue ich bei XDEV die jre-1.8.

 

[LimDul]

Ein JRE brauchst du nicht, das JDK reicht.

 

[Gelöschtes Mitglied 82461]

Achso. Dann ändere ich das mal...

 

[Gelöschtes Mitglied 82461]

Habe jetzt in XDEV das JDK eingebunden und einfach nur ein neues GUI-Fenster erstellt und es kommt folgende Meldung, wenn ich mit dem Cursor über den rot unterstrichenen Text streiche (Anhang).
Wenn ich das JRE aktiviere funktioniert alles reibungslos.

 

[philanthrop]

Ab Version 13 sind die Switch-Ausdrücke möglich: https://www.baeldung.com/java-switch#switch-expressions (lambda-Schreibweise, return ...)

Ich würde dir empfehlen, das JDK 17 LTS zu installieren, dann bist du quasi immer sicher.

Bitte kein Mix der JRE und JDK Versionen...

 

[philanthrop]

Habe jetzt in XDEV das JDK eingebunden und einfach nur ein neues GUI-Fenster erstellt

Ich glaube, du meinst das https://xdev.software/produkte/swing-builder oder?

 

[Gelöschtes Mitglied 82461]

Ja

 

[Gelöschtes Mitglied 82461]

Ab Version 13 sind die Switch-Ausdrücke möglich: https://www.baeldung.com/java-switch#switch-expressions (lambda-Schreibweise, return ...)

Ich würde dir empfehlen, das JDK 17 LTS zu installieren, dann bist du quasi immer sicher.

Bitte kein Mix der JRE und JDK Versionen...

Heißt ich lösche das JRE 1.8 und JDK 20 und installiere nur das JDK 17 ?!

 

[philanthrop]

Si

 

[Gelöschtes Mitglied 82461]

Habe es jetzt installiert und es geht immer noch nicht als Anhang die Informationsdatei des JDKs.
Habe ich das richtige installiert?

 

[philanthrop]

Eventuell die Umgebungsvariablen noch richtig konfigurieren ...



Was passiert, wenn du im Terminal "java --version" aufrufst?

 

[Gelöschtes Mitglied 82461]

Gebe ich dort einfach den jdk-17 ordner an oder eine bestimmte Datei? Wie ich das bei dir sehe den bin-Ordner?

 

[philanthrop]

Gebe ich dort einfach den jdk-17 ordner an oder eine bestimmte Datei? Wie ich das bei dir sehe den bin-Ordner?

bei JAVA_HOME den Pfad zum jdk und bei Path den Pfad zum bin-Ordner

 

[Gelöschtes Mitglied 82461]

Bitte Verzeihe mir meine aktuelle Kurzsichtigkeit 😕
aber bei Path sind neben meinem ...\bin viele andere Pfade. Egal?
und Java_Home existiert nicht. Soll ich es neu erstellen?

 

[philanthrop]

JAVA_HOME bitte neu erstellen
und Path einen neuen Eintrag hinzufügen

Edit: bitte auf Bearbeiten... klicken

 

[Gelöschtes Mitglied 82461]

Ok.
Die anderen Einträge stören aber nicht oder?

 

[philanthrop]

Die anderen Einträge stören aber nicht oder?

Falls da noch Einträge zu anderen jdk bin Verzeichnissen sind, diese entfernen

 

[Gelöschtes Mitglied 82461]

Also dann so?

 

[philanthrop]

Jup... und auf Ok klicken

 

[Gelöschtes Mitglied 82461]

Und für was war das jetzt? Das Problem aus #22 besteht immernoch
Lg und tausend Dank dass du mir hilfst

 

[philanthrop]

Was passiert, wenn du im Terminal "java --version" aufrufst?

?

 

[Gelöschtes Mitglied 82461]

also "java --17"?

 

[philanthrop]

Ne, einfach java --version

Ich hab XDEV nicht installiert, es kann sein, dass du dort das passende JDK noch einstellen musst

 

[Gelöschtes Mitglied 82461]

!

 

[philanthrop]

Jup, das ist ok

 

[Gelöschtes Mitglied 82461]

Ich hab XDEV nicht installiert, es kann sein, dass du dort das passende JDK noch einstellen musst

Habe ich bereits gemacht (Anhang). In diesem Video (Xdev-Tutorial von XDEV) wird es auch ab Minute 07:18 erwähnt.

 

[Gelöschtes Mitglied 82461]

Wobei wir uns jetzt rein in Xdev bewegen und nicht mehr in Java. Ich frage vielleicht lieber mal in einem Xdev-Forum, da das hier auch schon längst nichts mehr mit dem Thread Titel zutun hat...

 

[philanthrop]

Ja, das ist schon mal gut... Jetzt musst du diese Einstellungen nur noch für das aktuelle Projekt anwenden oder ein neues erstellen...

 

[philanthrop]

Wobei wir uns jetzt rein in Xdev bewegen und nicht mehr in Java. Ich frage vielleicht lieber mal in einem Xdev-Forum, da das hier auch schon längst nichts mehr mit dem Thread Titel zutun hat...

Ok

 

[Gelöschtes Mitglied 82461]

Ja, das ist schon mal gut... Jetzt musst du diese Einstellungen nur noch für das aktuelle Projekt anwenden oder ein neues erstellen...

Nach wie vor #22

Ich versuche es mal woanders.
Trotzdem vielen vielen Dank dir und auch euch anderen für eure außerordentlich schnelle,hilfreiche und vor allem NETTE (ist nicht in allen Foren selbstverständlich...leider) Hilfe
Liebe Grüße und ein schönes Wochenende noch
Benjamin

 

[philanthrop]

Nach wie vor #22

der Code sieht nicht richtig aus, kenne Xdev aber nicht...

Trotzdem vielen vielen Dank dir und auch euch anderen

👍

 

[M.L.]

Grundlagen ...HashMap

Generell gilt es in der SW-Entwicklung (unabhängig von Java oder XDEV) von einer häufig(er)en Änderung oder Erweiterung des Codes auszugehen (es könnten ja mehr Auswahlmöglichkeiten dazukommen oder verschwinden) und diese an einer (zentralen) Stelle vorzunehmen. Statt switch/case oder if/else-Konstruktionen könnte man z.B. die genannte (Hash)Map verwenden: https://www.baeldung.com/java-replace-if-statements