Mehrere Werte in einem Switch Case parallel überprüfen

[Karlter]

Hey Leute, ich befinde mich aktuell immer noch bei den Grundlagen in Java und frage mich bei der folgende Aufgabe, ob es dort wohl eine smartere Lösung gibt, als ich sie gerade in meinem Kopf habe. Ich suche ungern eine vollständige Lösung, sondern viel mehr einen Denkanstoß. Daher meine Frage - ich befinde mich im zweiten Teil der Aufgabe und frage mich, ob es eine Möglichkeit gibt in Java mehrere int Werte in einem einzigen Case zu prüfen. Oder ist es wirklich Sinn und Zweck der Aufgabe jetzt jeden einzelnen Case von 50 - 100 runterzucoden, um jeden Wert abzufangen? Danke schon mal für Euren Input





Und das ist mein Code bisher:

public static void main(String[] args) {

Scanner scanner = new Scanner(System.in);
System.out.println("Bitte geben Sie die maximal zu erreichenden Punkte in der Klausur ein.");
double maximalpunktzahl = scanner.nextInt();
System.out.println("Bitte geben Sie die erreichten Punkte ein");
double erreichtePunkte = scanner.nextDouble();
scanner.close();

double erreichteProzent = (100 / maximalpunktzahl) * erreichtePunkte;
System.out.printf("Die erreichte Prozentanzahl liegt bei %.2f Prozent!", erreichteProzent);
System.out.println();

if (erreichteProzent >= 95) {

System.out.println("Dies enspricht der Note 1,0!");

} else if (erreichteProzent < 95 & erreichteProzent >= 90) {

System.out.println("Dies entspricht der Note 1,3");

} else if (erreichteProzent < 90 & erreichteProzent >= 85) {

System.out.println("Dies entspricht der Note 1,7");

} else if (erreichteProzent < 85 & erreichteProzent >= 80) {

System.out.println("Dies entspricht der Note 2,0");

} else if (erreichteProzent < 80 & erreichteProzent >= 75) {

System.out.println("Dies entspricht der Note 2,3");

} else if (erreichteProzent < 75 & erreichteProzent >= 70) {

System.out.println("Dies entspricht der Note 2,7");

} else if (erreichteProzent < 70 & erreichteProzent >= 65) {

System.out.println("Dies entspricht der Note 3,0");

} else if (erreichteProzent < 65 & erreichteProzent >= 60) {

System.out.println("Dies entspricht der Note 3,3");

} else if (erreichteProzent < 60 & erreichteProzent >= 55) {

System.out.println("Dies entspricht der Note 3,7");

} else if (erreichteProzent < 55 & erreichteProzent >= 50) {

System.out.println("Dies entspricht der Note 4,0");

} else if (erreichteProzent < 50) {

System.out.println("Dies entspricht der Note 5,0");

}


switch ((int) erreichteProzent) {

case 95-100: System.out.println("Dies entspricht der Note 1,0");

case 90-94: System.out.println("Dies entspricht der Note 1,3");

case 85-89:




}






}



}

 

[Manul]

Die Aufgabenstellung scheint mir an dieser Stelle auch etwas Quatsch zu sein. Switch-Statements in Java sind nicht für Ranges gedacht, und um mehrere ifs wirst du hier nicht herumkommen. Was du allerdings machen könntest ist die Redundanz und die kognitive Komplexität durch geschickte Auslagerung in eine private Methode zu verringern.

 

[Manul]

Spontan fiele mir sowas hier ein:

int erreichteProzent =  ... // lt. Aufgabenstellung ist "erreichteProzent" eine Ganzzahl, also kein double
...
double note = zuNote(erreichteProzent);
// Pseudocode ...
// hier natürlich "note" z.B. mittels MessageFormat entsprechend der Aufgabenstellung ausgeben:
System.out.println("Dies enspricht der Note <note>!");

...

private double zuNote(int erreichteProzent) {
    if (erreichteProzent >= 95) {
        return 1.0;
    }
    ...
    else { // das entspricht dem letzten "if (erreichteProzent < 50)"
        return 5.0;
    }
}

 

[KonradN]

Also wenn man dies mit switch Statements abbilden möchte, dann kann man sich die Daten im Detail ansehen:
Es fällt auf, dass es immer 5er Blöcke sind. Dadurch ist es möglich, dass man die Prozentzahl durch 5 teilen kann und man hat dann statt 100 möglicher Werte nur noch 20 Werte.
Diese kann man dann mit 20 case abbilden.

Und dann sind die Änderungen in modernem Java interessant (Wenn ihr ältere Java Versionen nutzt, dann stehen diese Möglichkeiten vermutlich nicht zur Verfügung! Das also prüfen). So kann man in einem case mehrere Werte auflisten;

case 0, 1, 2, 3, 4, 5, 6, 7, 8, 9:

Eine weitere moderne Änderung an dem switch Befehl sind die "guard" Erweiterungen. Das ist aber hier nicht wirklich sinnvoll, dass ich beim case nichts sinnvolles habe. Aber denkbar wäre etwas wie:

switch (true) {
    case true when prozente < 50:
        // ...
    case true when prozente >= 50 && prozente < 55:
        // ...
}

Man erkennt also, dass das eigentliche case Unsinn ist und lediglich die Bedingungen der bisherigen if Anweisungen in die guard Expressions gerückt sind. Das macht so also eigentlich keinen Sinn - aber es wäre technisch möglich.

Das alles findet sich im Detail in der JLS in der Beschreibung des switch statements:

Chapter 14. Blocks, Statements, and Patterns

Die jeweiligen relevanten Änderungen und ab wann diese zur Verfügung stehen, habe ich jetzt nicht heraus gesucht.

 

[Oneixee5]

Ich denke man teilt die Punke durch 5 und hat dann noch maximal 10 Fälle. Alles unter 'Punkte geteilt durch 2' muss man nicht weiter untersuchen.

 

[Manul]

Ich denke man teilt die Punke durch 5 und hat dann noch maximal 10 Fälle. Alles unter 'Punkte geteilt durch 2' muss man nicht weiter untersuchen.

Wenn sowas im Produktivcode meiner Kollegen landen würde, würde ich sagen:
Viel Spaß an alle die diesen Code später noch mal verstehen und warten wollen/müssen

 

[KonradN]

Produktivcode

Ich habe ja immer die Hoffnung, dass die Leute da dann ordentlich arbeiten. Und dann sowas in vernünftigen Datenstrukturen abbilden.

Nur eben ist das halt eine einfache Schulaufgabe und da geht es (vermutlich) um ein Verständnis von Algorithmen und Co.

Wie man das dann gezielt abbilden will, ist mir dabei noch relativ egal. Man kann da rein Datenorientiert heran gehen und dann hat man halt einen Datensatz mit Bewertung, min Prozente, max Prozente und Note und die kann man dann durchgehen um den passenden Datensatz zu finden.

Da man hier eine feste Anzahl Noten hat, könnte man da auch an eine Enumeration denken.

Wenn man nicht über die paar Einträge iterieren möchte, dann kann man da auch gerne eine TreeMap nutzen oder so. Aber das sind dann alles Details, die halt nicht in einer Aufgabe für Java Anfänger zu suchen hat.

 

[Blender3D]

Die Aufgabenstellung scheint mir an dieser Stelle auch etwas Quatsch zu sein. Switch-Statements in Java sind nicht für Ranges gedacht, und um mehrere ifs wirst du hier nicht herumkommen. Was du allerdings machen könntest ist die Redundanz und die kognitive Komplexität durch geschickte Auslagerung in eine private Methode zu verringern.

Stimmt alles abgesehen davon, dass das auch ohne if machbar ist.

 

[Karlter]

Hey Leute, erstmal vielen Dank für Eure Beiträge! Ja also was die Redundanz betrifft wäre es natürlich sinnvoller einfach eine Methode runter zuschreiben, allerdings war das hier nicht Sinn der Sache, da ausschließlich Kontrollstrukturen genutzt werden sollen. Ich habe das ganze jetzt so umgesetzt, wie in dem Beitrag von @KonradN beschrieben. Ich hatte nur leider die Auflistung mehrerer Werte in Java in einem einzigen Case nicht auf dem Schirm. Ansonsten funktioniert nun alles, das sollten den Anforderungen der Aufgabe erstmal genügen Danke Euch!

 

[Blender3D]

Hier eine Variante die auf Bedingungen verzichtet. Das wird durch die Verwendung von Arrays (LookUpTable ) und mathematische Begrenzung der Limits erreicht.

public class StartTestMarkFinder {

    public static void main(String[] args) {
        int[] points = { 0, 34, 49, 50, 54, 55, 59, 60, 64, 65, 69, 70, 74, 75, 79, 80, 84, 85, 89, 90, 94, 95, 100 };
        MarkFinder findMark = new MarkFinder(100);
        for (int p : points) {
            findMark.setPoints(p);
            System.out.println(findMark);
        }
    }
}

public class MarkFinder {
    private static double[] mark = { 5, 4, 3.7, 3.3, 3, 2.7, 2.3, 2, 1.7, 1.3, 1 };
    private static String[] rating = { "sehr gut", "gut", "befriedigend", "ausreichend", "nicht ausreichend" };
    public final int maxPoint;
    private final int PERCENT_STEP = 5;
    private int points = 0;

    public MarkFinder(int maxPoint) {
        this.maxPoint = maxPoint;
    }

    private static int getLimitDifference(int id) {
        return ((id + Math.abs(id) - 2 * Math.abs(id))) / 2;
    }

    private double getMark() {
        return mark[getMarkId()];
    }

    private int getMarkId() {
        int maxId = mark.length - 1;
        int id = (((int) (getPercent()) / PERCENT_STEP) - maxId) + 1;
        return id - getLimitDifference(id) + getLimitDifference(maxId - id);
    }

    public double getPercent() {
        return (100d / maxPoint) * points;
    }

    public String getRating() {
        return rating[(int) Math.round(getMark()) - 1];
    }

    private String getTab() {
        StringBuilder tmp = new StringBuilder();
        for (int i = 0; i < 20 - getRating().length(); i++)
            tmp.append(" ");
        return tmp.toString();
    }

    public void setPoints(int points) {
        if (points < 0 || points > maxPoint)
            throw new IllegalArgumentException("Invalid point value!");
        this.points = points;
    }

    @Override
    public String toString() {
        return String.format("%s%s%2.2f\t%s", getRating(), getTab(), getPercent(), getMark());
    }

}

 

[Manul]

Stimmt, die Variante die paar ifs durch totales Overengineering zu ersetzen hatte ich nicht bedacht
Auch hier gilt: viel Spaß an alle beim Verstehen dieses Codes ...

 

[thecain]

Eine TreeMap müsste das eigtl von Haus aus können, mit floorEntry, wenn ich jetzt keine Anforderung überlese. Dann bräuchte man keine eigene Lookup Implementierung. Für die Aufgabe aber wahrscheinlich irrelevant, da ifs oder switches gefragt sein werden...

 

[Blender3D]

Eine TreeMap müsste das eigtl von Haus aus können, mit floorEntry, wenn ich jetzt keine Anforderung überlese. Dann bräuchte man keine eigene Lookup Implementierung. Für die Aufgabe aber wahrscheinlich irrelevant, da ifs oder switches gefragt sein werden...

Die Aufgabenstellung verlangt ja switch und oder ifs..
Die Lookup Variante war dafür gedacht, dass ich nachdem ich @Manul 's Post #2 bis auf

und um mehrere ifs wirst du hier nicht herumkommen.

zugestimmt hatte, lediglich aufzuzeigen dass es auch ohne if geht.

Eine TreeMap benutzt bei jedem Zugriff Bedingungen ist aber auf jedem Fall eine guter Ansatz für so eine Problemstellung.
Also man braucht dafür selbstverständlich keine Lookup Variante.

 

[Ullenboom]

Eine interessante Aufgabe, die in ähnlicher Form gut in mein Captain-CiaoCiao-Buch beim Thema Aufzählungstypen passen würde. Fortgeschrittene Lösung würde ich sagen

import static java.lang.Math.nextDown;

enum Grade {

  _5_0, _4_0, _3_7, _3_3, _3_0, _2_7, _2_3, _2_0, _1_7, _1_3, _1_0;

  static Grade fromPercentage( double percentage ) {
    double[] percentageRanges = {
        nextDown( 50. ), nextDown( 55. ), nextDown( 60. ), nextDown( 65. ), nextDown( 70. ),
        nextDown( 75. ), nextDown( 80. ), nextDown( 85. ), nextDown( 90. ), nextDown( 95. ), 100 };

    int index = Arrays.binarySearch( percentageRanges, percentage );
    return values()[ index >= 0 ? index : -(index + 1)];
  }
}

Dann haben wir auch das switch:

Grade grade = Grade.fromPercentage( 59.99 );
System.out.println( switch ( grade ) {
  case _1_0, _1_3 -> "Sehr gut";
  case _1_7, _2_0, _2_3 -> "Gut";
  case _2_7, _3_0, _3_3 -> "Befriedigend";
  case _3_7, _4_0 -> "Ausreichend";
  case _5_0 -> "Nicht ausreichend";
} );

 

[KonradN]

Eine interessante Aufgabe, die in ähnlicher Form gut in mein Captain-CiaoCiao-Buch beim Thema Aufzählungstypen passen würde. Fortgeschrittene Lösung würde ich sagen

Also mir gefällt diese Lösung mit dem enum so nicht, wenn Du hast die Grenzen separat in dem Array und nutzt dann den Index um damit ein Element zu finden. Die Grenzen gehören aber doch direkt zu den Elementen. Daher würde ich die direkt mit hinein packen.

(Ich zeige jetzt meine generellen Gedankengänge beim Refactoring - einfach ganz ans Ende springen um zu sehen, was ich eher als "Enum Musterlösung" würde.)

Also ein erstes Refactoring wäre dann etwas wie:

import java.util.Arrays;
import java.util.Comparator;

import static java.lang.Math.nextDown;

enum Grade {

    _5_0(nextDown(50.)),
    _4_0(nextDown(55.)),
    _3_7(nextDown(60.)),
    _3_3(nextDown(65.)),
    _3_0(nextDown(70.)),
    _2_7(nextDown(75.)),
    _2_3(nextDown(80.)),
    _2_0(nextDown(85.)),
    _1_7(nextDown(90.)),
    _1_3(nextDown(95.)),
    _1_0(100);

    private final double percentRange;

    Grade(double percentRange) {
        this.percentRange = percentRange;
    }
    public double getPercentRange() {
        return percentRange;
    }
    static Grade fromPercentage( double percentage ) {

        return Arrays.stream(Grade.values())
                .filter(g -> g.getPercentRange() > percentage)
                .sorted(Comparator.comparingDouble(Grade::getPercentRange))
                .findFirst().orElseThrow(() -> new IllegalArgumentException("percentage not valid (" + percentage + ")"));
    }
}

Ich würde aber noch einen Schritt weiter gehen und generell die Grenzen speichern als obere und untere Grenze. Das wäre dann etwas, das dann so aussehen würde:

import java.util.Arrays;
import java.util.Comparator;

import static java.lang.Math.nextDown;

enum Grade {

    _5_0(0, 50),
    _4_0(50, 55),
    _3_7(55, 60),
    _3_3(60, 65),
    _3_0(65, 70),
    _2_7(70, 75),
    _2_3(75, 80),
    _2_0(80, 85),
    _1_7(85, 90),
    _1_3(90, 95),
    _1_0(95, 100);

    private final double includedLowestValue;
    private final double excludedUpperValue;

    Grade(double includedLowestValue, double excludedUpperValue) {
        this.includedLowestValue = includedLowestValue;
        this.excludedUpperValue = excludedUpperValue;
    }
    static Grade fromPercentage( double percentage ) {
        return Arrays.stream(Grade.values())
                .filter(g -> g.includedLowestValue <= percentage && percentage < g.excludedUpperValue)
                .findAny().orElseThrow(() -> new IllegalArgumentException("percentage not valid (" + percentage + ")"));
    }
}

Das wäre dann vermutlich die Lösung, die ich bevorzugen würde - wobei ich vermutlich ohne Arrays.stream arbeiten würde:

    static Grade fromPercentage( double percentage ) {
        for (Grade grade : Grade.values()) {
            if (grade.includedLowestValue <= percentage && percentage < grade.excludedUpperValue) {
                return grade;
            }
        }
        throw new IllegalArgumentException("percentage not valid (" + percentage + ")");
    }

Damit würde ich als Musterlösung für eine Enum Lösung eher vorschlagen:

import java.util.Arrays;
import java.util.Comparator;

import static java.lang.Math.nextDown;

enum Grade {

    _5_0(0, 50),
    _4_0(50, 55),
    _3_7(55, 60),
    _3_3(60, 65),
    _3_0(65, 70),
    _2_7(70, 75),
    _2_3(75, 80),
    _2_0(80, 85),
    _1_7(85, 90),
    _1_3(90, 95),
    _1_0(95, 100);

    private final double includedLowestValue;
    private final double excludedUpperValue;

    Grade(double includedLowestValue, double excludedUpperValue) {
        this.includedLowestValue = includedLowestValue;
        this.excludedUpperValue = excludedUpperValue;
    }
    static Grade fromPercentage( double percentage ) {
        for (Grade grade : Grade.values()) {
            if (grade.includedLowestValue <= percentage && percentage < grade.excludedUpperValue) {
                return grade;
            }
        }
        throw new IllegalArgumentException("percentage not valid (" + percentage + ")");
    }
}

 

[Ullenboom]

Formuliert als Aufgabe in der Java-Aufgabensammlung: https://tutego.de/javabuch/aufgaben/interface_enum_sealed_classes_record.html#_aufzählungstypen_enum

 

[Leistungsigel]

@Ullenboom Darf ich dich fragen, weshalb doch noch hier schreibst?

(a) zu Konrads "Musterlösung" ist keine abweichende Meinung erlaubt,

(b) in der ersten Antwort werden Dinge behauptet, die faktisch falsch sind ...

 

[KonradN]

Darf man fragen:
a) warum du ständig neue Accounts erstellst? Du bist hier doch sehr offensichtlich nicht willkommen.
b) wieso sollte eine andere Meinung nicht erlaubt sein? Ich finde es lustig, dass du mir meine Meinung verbieten willst - und das, wo ich sogar versuche meine Sicht zu begründen. Und ganz offensichtlich akzeptiere ich eine abweichende Meinung, denn ich habe ja nicht weiter die Lösung kritisiert (einmal meine Meinung sagen reicht ja auch … darf ja jeder anders sehen)
c) wenn du meinst, dass etwas falsch ist, dann benenne es doch bitte im Detail.

Und die große Frage ist natürlich: willst du nun versuchen, vernünftig und sachlich zu bleiben oder sollen wir wieder direkt bei erster Sichtung löschen?

 

[DefconDev]

Habe nur die etliche Switch Cases gesehen und dann ein paar Code Schnipsel von euch aber mein Vorschlag wäre folgender:

private static TreeMap<Integer,String> grades = new TreeMap<>();


    public static void main(String[] args) {
        int result = 94;
        grades.put(95, "Dies enspricht der Note 1,0!");
        grades.put(90, "Dies enspricht der Note 1,3!");
        grades.put(85, "Dies enspricht der Note 1,7!");
        grades.put(80, "Dies enspricht der Note 2,0!");
        grades.put(75, "Dies enspricht der Note 2,3!");
        grades.put(70, "Dies enspricht der Note 2,7!");
        grades.put(65, "Dies enspricht der Note 3,0!");
        grades.put(60, "Dies enspricht der Note 3,3!");
        grades.put(55, "Dies enspricht der Note 3,7!");
        grades.put(50, "Dies enspricht der Note 4,0!");
        grades.put(0, "Dies enspricht der Note 5,0!");

        int targetKey = 0;
        for(int key : grades.keySet()){
            if(result >= key){
                targetKey = key;
            }
        }
        System.out.println(grades.get(targetKey));
    }

 

[thecain]

Oder eben wie schon geschrieben einfach https://docs.oracle.com/javase/8/docs/api/java/util/TreeMap.html#floorEntry-K-

 

[DefconDev]

Oder eben wie schon geschrieben einfach https://docs.oracle.com/javase/8/docs/api/java/util/TreeMap.html#floorEntry-K-

Deinen Post hatte ich nicht wahrgenommen, weil kein Code enthalten war

Aber deine Variante ist noch besser mit der Methode floorEntry. Die kannte ich tatsächlich gar nicht. Wieder etwas dazugelernt

Statt meiner For Schleife einfach dann

System.out.println(grades.floorEntry(result).getValue());

 

[KonradN]

An der Stelle evtl. noch ein Hinweis zu der enum Variante (Speziell für @Ullenboom - evtl. interessant für ihn)

Wenn man den enum Instanzen keine Werte geben will oder der Meinung ist, dass die Grenzen der Bewertung da eben nicht hinzu gehören, dann wäre die TreeMap einer Alternative zur ArrayList und der Verwendung der Indices um dann das Enum Element auszuwählen.

Also etwas wie:

import java.util.TreeMap;

enum Grade {

    _5_0, _4_0, _3_7, _3_3, _3_0, _2_7, _2_3, _2_0, _1_7, _1_3, _1_0;

    private static TreeMap<Double, Grade> minimumPercentGradeMap = createMinimumPercentGradeMap();

    private static TreeMap<Double, Grade> createMinimumPercentGradeMap(){
        TreeMap<Double, Grade> result = new TreeMap<>();
        result.put(0., _5_0);
        result.put(50., _4_0);
        result.put(55., _3_7);
        result.put(60., _3_3);
        result.put(65., _3_0);
        result.put(70., _2_7);
        result.put(75., _2_3);
        result.put(80., _2_0);
        result.put(85., _1_7);
        result.put(90., _1_3);
        result.put(95., _1_0);
        return result;
    }

    static Grade fromPercentage( double percentage ) {
        return minimumPercentGradeMap.floorEntry(percentage).getValue();
    }
}

Dies hat halt den Vorteil, dass die Grenzen und die Prozent-Grenzen zusammen sind. Eine Veränderung der Reihenfolge oder so führt nicht zu Problemen, die schwer zu erkennen sind. Das erhöht die Lesbarkeit und vereinfacht z.B. die Anpassung der Grenzen.

Aber damit bin ich schon wieder raus, ehe ich Tobias wieder triggere.

 

[Robert Zenz]

Um auch noch was gesagt zu haben, ein aehnliches Konzept habe ich in meinem BMI-Rechner Beispiel, wobei es kein Enum ist sondern eine einfache Klasse wo die einzelnen 'Stufen' in eine Liste gepackt werden.

 

[Manul]

Hm, wir dürften mittlerweile alle Variationen dieses Implementierungsansatzes durch haben, oder?