Algorithmus entwicklen, der zu einem gegebenen Datum die Jahreszeit ermittelt

[Schrank12]

Hallo zusammen, ich habe in Informatik die Aufgabe bekommen einen Algorithmus zu erstellen.
Es gibt insgesamt 3 Eingabefelder und ein Button.
Erst zwei Eingabefelder, in denen man einmal ein Tag eingeben kann (1-31) und bei dem anderen Eingabefeld soll man ein Monat eingeben (1-12).
Daraufhin folgt ein Button und nach dem draufklicken auf dem Button soll bei dem letzten Eingabefeld erscheinen, um welche Jahreszeit es sich handelt.
Die Daten, die für mich gegeben sind:
Frühling: 21.3-20.6
Sommer: 21.6 - 22.9
Herbst: 23.9 - 20.12
Winter: 21.12 - 20.3

Nun meine Frage, welche Schleife würdet ihr empfehlen bzw. wie gebe ich die Daten am besten ein (<,>?)?
Ich hoffe ich habe es so gut es geht beschrieben. Ich würde mich auf einen kurzen Ansatz freuen.
Danke im Voraus.

 

[mihe7]

Nun meine Frage, welche Schleife würdet ihr empfehlen

Die allgemein bekannte, legendäre http://if-schleife.de

wie gebe ich die Daten am besten ein (<,>?)?

Du meinst, wie Du die Daten am besten miteinander vergleichst? Da gibt es verschiedene Ansätze und die hängen davon ab, was Du verwenden darfst.

Im echten Leben würde man z. B. https://docs.oracle.com/javase/8/docs/api/java/time/MonthDay.html im Zusammenhang mit den Methoden compareTo, isAfter und/oder isBefore verwenden. Wenn Du das nicht darfst, musst Du die Werte halt einzeln als Zahlen miteinander vergleichen (<, >, <=, >=, usw.)

 

[Schrank12]

Die allgemein bekannte, legendäre http://if-schleife.de


Du meinst, wie Du die Daten am besten miteinander vergleichst? Da gibt es verschiedene Ansätze und die hängen davon ab, was Du verwenden darfst.

Im echten Leben würde man z. B. https://docs.oracle.com/javase/8/docs/api/java/time/MonthDay.html im Zusammenhang mit den Methoden compareTo, isAfter und/oder isBefore verwenden. Wenn Du das nicht darfst, musst Du die Werte halt einzeln als Zahlen miteinander vergleichen (<, >, <=, >=, usw.)

Ich darf <,> diese Zeichen benutzen aber ich weiß nicht welche Schleife ich benutzen soll und ich brauche einen Ansatz..

 

[KonradN]

Wenn du keine weiteren Klassen benutzen darfst, dann hast du nur die Zahlen.

Woe kriegst du es denn heraus? wenn ich dir den 30.3 nenne: was machst du, um die Jahreszeit heraus zu bekommen?

Kannst du es ggf formalisieren, d.h. Regeln aufstellen?

evtl. kannst du ja für jeden Monat eine Aussage treffen? (und dann wäre ggf. ein switch Statement hilfreich)

 

[Neumi5694]

Man kann auch den umgekehrten Weg gehen. Man erstelle das Datum (im selben Jahr), in dem der Frühling anfängt.
Dann verwendet man den Standard-Komparator, um zu sehen, ob das angegebene Datum davor liegt.
(oder umwandeln in einen Timestamp, dann braucht man nur noch einen einfachen Zahlenvergleich).
Falls ja, dann ist es Winter.
Falls nicht, dann das gleiche Spiel mit dem Beginn des Sommers usw.
Wenig Fallunterscheidungen, nur maximal 4 Vergleiche.

 

[temi]

aber ich weiß nicht welche Schleife ich benutzen soll

Also generell sind Schleifen austauschbar, es ist ziemlich egal welche man benutzt. Mit der "richtigen" Schleife ist es halt einfacher/übersichtlicher.

In deinem Fall lautet die Antwort: gar keine.

Richtig wäre: siehe Antwort #2

 

[Jw456]

Ich darf <,> diese Zeichen benutzen aber ich weiß nicht welche Schleife ich benutzen soll und ich brauche einen Ansatz..

Wie schon gesagt wurde du brauchst keine Schleife. Ein if ist keine Schleife.

Mache dir das erstmal klar.

 

[Arrive5784]

Es ist korrekt, dass er eine Schleife benötigt.

Beispiel:

public class JahreszeitBestimmen {
    private final int[][][] jahreszeiten = {
            {{21, 3}, {20, 6}},
            {{21, 6}, {22, 9}},
            {{23, 9}, {20, 12}},
            {{21, 12}, {20, 3}}
    };

    public int datumZuTag(int tag, int monat) {
        tag--;
        monat--;
        return Math.round(365f / 12f * monat + tag);
    }

    public String datumZuJahreszeit(int tag, int monat) {
        String[] a = {
                "Frühling", "Sommer", "Herbst", "Winter"
        };
        for (int i = 0; i < jahreszeiten.length - 1; i++) {
            int[][] b = jahreszeiten[i];
            if (datumZuTag(b[0][0], b[0][1]) <= datumZuTag(tag, monat) && datumZuTag(b[1][0], b[1][1]) >= datumZuTag(tag, monat)) {
                return a[i];
            }
        }
        return a[3];
    }

    public static void main(String[] args) {
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(21, 3));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(21, 6));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(23, 9));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(21, 12));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(20, 6));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(22, 9));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(20, 12));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(20, 3));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(1, 1));
        System.out.println(new JahreszeitBestimmen().datumZuJahreszeit(31, 12));
    }
}

 

[KonradN]

Es ist korrekt, dass er eine Schleife benötigt.

Nein, es geht natürlich auch ohne Schleife!

Es reicht einfach, den Monat zu prüfen. Wenn der Monat nicht eindeutig ist, dann prüft man zusätzlich den Tag. Und den Monat kann man sehr schön mit einem Switch prüfen um nicht zu viele if Abfragen zu haben.

Das geht somit alles sehr einfach auch ganz ohne jede Berechnung.

 

[Arrive5784]

Ich finde so viele if if else else... hässlich.

 

[KonradN]

Ich finde so viele if if else else... hässlich.

Daher nimmt man bei sowas ja auch ein Switch Befehl.

Und natürlich gibt es einige Refactorings, mit denen man sowas schöner schreiben kann. Eine Map kann hier z.B. interessant sein.

Bezüglich Deinem Code: Man könnte auf Gleitkomma-Berechnungen verzichten. Dann hat in der Berechnung jeder Monat halt 31 Tage... Den Wert eines Tages berechnet man dann halt mit 31*Monat + Tag. Damit könnte man dann Bereiche angeben. Das ganze dann in eine Enum und jeder Enum-Wert kennt den Wertebereich. Da der Winter ja überlappt, kann man bei jedem Wert angeben, ob die Grenzen eingehalten werden sollen oder nicht. Dann würde sowas dabei heraus kommen. Auch wieder mit einer Schleife, wobei die einfach durch 4 if Abfragen ersetzt werden könnte (Was ich nicht machen würde, aber egal):

package entities;

public enum Season {
    SPRING(true, getDayValue(21,3), getDayValue(20, 6)),
    SUMMER(true, getDayValue(21,6), getDayValue(22, 9)),
    AUTUMN(true, getDayValue(23,9), getDayValue(20,12)),
    WINTER(false, getDayValue(21,3), getDayValue(20,12));


    private boolean isInside;
    private int start;
    private int end;
    Season(boolean isInside, int start, int end) {
        this.isInside = isInside;
        this.start = start;
        this.end = end;
    }

    public boolean isInside(int day, int month) {
        int dayValue = getDayValue(day, month);
        return isInside(dayValue);
    }

    private boolean isInside(int dayValue) {
        return (isInside == (dayValue >= start && dayValue <= end));
    }

    private static int getDayValue(int day, int month) {
        return day + 31*month;
    }

    public static Season getSeason(int day, int month) {
        int dayValue = getDayValue(day, month);
        for (Season season : Season.values()) {
            if (season.isInside(dayValue)) return season;
        }
        throw new IllegalArgumentException("Argument does not belong to any entities.Season!");
    }
}

package entities;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class SeasonTest {
    @Test
    public void testSeasonEnum() {
        assertAll(
                () -> Assertions.assertEquals(Season.SPRING, Season.getSeason(21,3)),
                () -> Assertions.assertEquals(Season.SPRING, Season.getSeason(20,6)),
                () -> Assertions.assertEquals(Season.SUMMER, Season.getSeason(21,6)),
                () -> Assertions.assertEquals(Season.SUMMER, Season.getSeason(22,9)),
                () -> Assertions.assertEquals(Season.AUTUMN, Season.getSeason(23,9)),
                () -> Assertions.assertEquals(Season.AUTUMN, Season.getSeason(20,12)),
                () -> Assertions.assertEquals(Season.WINTER, Season.getSeason(21,12)),
                () -> Assertions.assertEquals(Season.WINTER, Season.getSeason(20,3))
        );
    }
}

Also ja - sowas kann durchaus Sinn machen. Aber das wäre etwas, das ich in den JavaDoc Kommentaren etwas erläutern würde. Und die Unit Tests sind natürlich nur minimal.

Also ja - von der Logik her würde ich auch eher sowas aufgreifen, wie Du es schon geschrieben hast in Deinem Code (Wenn auch dann in anderer Form) aber bei der Aufgabe geht es wohl eher um Starter und die sollen hier vermutlich nur Bedingungen tiefer kennen lernen und (meine Vermutung) hier evtl. die switch Anweisung nutzen.

 

[Arrive5784]

Danke für den ausführlichen Beitrag.

for (Season season : Season.values()) {

Schleife entdeckt!

 

[Arrive5784]

Unsere zwei Ansätze gelten aber nur, wenn das von @mihe7 in #2 erwähnte MonthDay nicht verwendet werden darf oder nicht eingesetzt werden soll.

 

[KonradN]

Schleife entdeckt!

Daher ja auch meine Aussage: "Auch wieder mit einer Schleife, wobei die einfach durch 4 if Abfragen ersetzt werden könnte (Was ich nicht machen würde, aber egal)"

Mit dem MonthDay würde das bei mir lediglich das "getDayValue" ersetzen um da dann mit isBefore / isAfter zu arbeiten. Aber vom generellen Aufbau würde sich sonst nicht viel ändern.

Und an der Stelle möchte ich nur kurz abschweifen - es gab eine Diskussion im Forum, wo sowas auch etwas das Thema war (Clean Code / testen privater Methoden. Weiss nicht mehr, mit wem die Diskussion damals war. @yfons123? @Neumi5694? Ich erinnere mich nicht mehr.:
Wenn so eine Klasse noch nicht existieren würde, wäre es sogar naheliegend, so eine Klasse selbst einzuführen:
- Zum einen diese int Parameter im Konstruktor. int start, int end - da steckt ja deutlich mehr dahinter als ein reiner int. Auch eine Funktionalität, denn die Werte generiere ich ja mit einer Methode.
- die private Methode getDayValue - die ist ja nicht direkt zu testen. Auch so ein Anzeichen, das einem sagt: Gehört das so hier wirklich hin? Oder gehört das woanders hin und wäre dann gar etwas, das getestet werden kann?
Es deutet also vieles darauf hin, dass dies so nicht nicht wirklich Clean Code ist und dass man sich zumindest überlegen sollte, da etwas zu ändern. Ob man das direkt verändert hängt vom Umfeld ab. Wenn das (relativ sicher) nicht woanders gebraucht wird, dann lasse ich es vermutlich sogar. Wenn ich in einer Library bin, dann würde ich es heraus ziehen um an der Stelle einfach sauberer zu sein (und kostet ja auch nicht viel Zeit, denn die Funktionalität wäre nur das, was gebraucht wird. Hier also intern der int Wert, die Methode getDayValue wird der Konstruktor und für Vergleiche gibt es isBefore und isAfter.)
Das aber einfach als kleiner Exkurs, weil da halt auch Erinnerungen aufkommen an vergangene Diskussionen.