{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- Die Klasse heißt bei dir `FlatRateCart`, gefordert ist aber `FlatRateCard` (auch im Beispielcode der Aufgabe); mit dem aktuellen Namen passt `new FlatRateCard()` nicht und die Vorgabe wird verfehlt.\n- `FlatRateCart.cost()` liefert immer 150 CHF, unabhängig davon, ob überhaupt geparkt wurde; damit wird der geforderte Gesamtumsatz von 156.75 CHF mit den gegebenen Parkvorgängen nicht erreicht (du würdest alleine durch die Flatrate schon +150 haben).\n- In `ParkingSystemExample` ist zusätzlicher Code mit `List.of(...)` und anschließendem `colors.add(...)`; das führt zur Laufzeit zu einer Exception und verhindert, dass das Programm wie gefordert sauber läuft und den Umsatz ausgibt.\n\n### Suggestion\n- Prüfe Klassennamen/Dateinamen exakt gegen die Aufgabenstellung und den erwarteten Beispiel-Aufruf in `ParkingSystemExample` (insbesondere `FlatRateCard` vs. `FlatRateCart`).\n- Überlege, wann die 150 CHF bei einer Abo-Karte tatsächlich in die Einnahmen einfließen sollen: bei jedem `cost()`-Aufruf, oder nur wenn die Karte im Abrechnungszeitraum “aktiv” war (z.B. mindestens einmal geparkt)? Passe deine Logik so an, dass die Beispielabfolge am Ende 156.75 CHF ergibt.\n- Entferne oder entschärfe den Listenteil im Example, oder ändere ihn so, dass keine Exception entsteht (und dass er nicht vom eigentlichen Ziel “ParkingSystem demonstrieren” ablenkt).\n\n### Code Style\n- In `GroupCard` sollten Felder wie `noOfPeople`, `HOURLY_RATE`, `totalTime` sinnvoll gekapselt werden (z.B. `private`, und Konstanten/Instanzvariablen sauber benennen); aktuell sind sie package-private und teils in ALLCAPS ohne `static final`.\n- Der Konstruktor von `GroupCard` ist package-private; wenn die Karten von außerhalb des Packages erzeugt werden sollen, wäre `public` konsistenter.\n- Unnötige Imports und Demo-Code in `ParkingSystemExample` (z.B. `import java.util.List;` + Farbenliste) entfernen, damit das Beispiel nur den geforderten Use-Case zeigt.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- Dein `BacktrackingAlgorithm` macht kein echtes Backtracking (kein Merken von Abzweigungen/Visited/Stack), sondern folgt effektiv einer festen Regel (Left-Hand-Rule). Damit ist nicht garantiert, dass du die “letzten Levels” allgemeingültig löst, wie in der Aufgabe gefordert.\n- In `LabyrinthApp` ist `main()` nicht `public static void main(String[] args)`. So wie es jetzt ist, startet die App in einer normalen Java-Umgebung typischerweise nicht über den Standard-Entry-Point.\n\n### Suggestion\n- Überlege dir für “Backtracking” eine Strategie, bei der du Entscheidungen speicherst: z.B. an Kreuzungen merken, welche Richtungen du schon ausprobiert hast, und wenn du in einer Sackgasse landest, gezielt zum letzten offenen Punkt zurückkehren und dort eine andere Option nehmen.\n- Prüfe die Signatur der Startmethode in `LabyrinthApp` und vergleiche sie mit dem, was Java als Einstiegspunkt erwartet; passe sie so an, dass das Programm wirklich ausführbar ist.\n\n### Code Style\n- In deiner Abgabe sind sehr viele Klassen (Figure, Labyrinth, LabyrinthGame, …) unverändert mitkopiert. Üblicherweise reicht es, nur die von dir neu erstellten/geänderten Klassen abzugeben, damit die Diff/Änderungen klar erkennbar bleiben.\n- `BacktrackingAlgorithm` heißt zwar so, implementiert aber eher “immer links, sonst gerade, sonst rechts, sonst umdrehen”; ein Name, der das Verhalten beschreibt, wäre konsistenter (oder du implementierst wirklich Backtracking passend zum Namen).\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist die `main`-Methode als `void main()` deklariert; so wird sie in Java nicht als Programmeinstieg erkannt (üblich ist eine `public static ...`-Signatur), dadurch startet das Programm u. U. gar nicht über den Runner/IDE.\n\n### Suggestion\n- Prüfe, welche Methodensignatur Java als Entry-Point erwartet und passe die `main`-Methode genau daran an (Zugriffsmodifizierer, `static`, Parameterliste).\n\n### Code Style\n- `volatile` für die `description`-Flags und die `Color`-Felder wirkt hier unnötig und lenkt eher ab; solange du nicht wirklich mit mehreren Threads arbeitest, reicht ein normales Feld.\n- In `ModeButton` sind `color1`/`color2` als Felder gespeichert, werden aber beim Hover jeweils per Swap vertauscht; das ist zwar okay, aber etwas schwer nachzuvollziehen. Lesbarer wäre ein expliziter Hover-Status (Boolean) und Farben abhängig davon wählen.\n- In `City.draw` setzt du Schriftattribute (`setFontSize`, `setBold`) ohne sie zurückzusetzen; je nach GUI-Bibliothek können solche globalen Zustände andere Komponenten beeinflussen.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Im `DataPoint`-Interface fehlen die geforderten Javadoc-Kommentare zur Dokumentation des erwarteten Verhaltens der Methoden.\n- In `DataPoint` deklarierst du `String toString();` explizit als Interface-Methode; das ist für die Aufgabenanforderung nicht nötig und kann zu Verwirrung führen, weil `toString()` bereits von `Object` kommt (und damit sowieso existiert).\n- `VisualizerApp`: Deine `main()`-Methode hat die Signatur `void main()` und ist nicht `static`. So kann das Programm typischerweise nicht als Java-Programm gestartet werden (üblich ist ein `public static void main(String[] args)` Einstiegspunkt).\n\n### Suggestion\n- Ergänze zu jeder Methode im `DataPoint`-Interface kurze Javadocs, die klar machen: was bedeutet X/Y-Achse, was ist “Name”, was ist “Group”, und wofür wird der Detailtext verwendet (z.B. Tooltip/Highlight).\n- Überlege dir, ob du wirklich `toString()` als Teil der “Schnittstelle” definieren willst, oder ob du stattdessen eine eigene Methode für den Detailtext bereitstellst (damit es nicht mit dem allgemeinen `toString()`-Konzept kollidiert).\n- Prüfe die erwartete Startmethode für eure Umgebung/Tests: falls die App nicht startet, liegt es sehr wahrscheinlich an der `main`-Signatur. Schau in anderen Übungen/Beispielen nach, welche Signatur vorausgesetzt wird.\n\n### Code Style\n- `DataPoint.java`: Der Import `ch.trick17.gui.component.Hoverable` wird nirgends verwendet und sollte entfernt werden.\n- `Movie`, `Country`, `Processor`: Methoden wie `getX()`, `getY()`, `getGroup()`, `getName()` könntest du mit `@Override` annotieren, damit der Compiler dir bei Tippfehlern/Signaturproblemen hilft.\n- `Processor.toString()`: Bei der Ausgabe der GHz-Werte erzeugst du evtl. sehr lange Dezimaldarstellungen (z.B. `2.500123GHz`). Für Lesbarkeit wäre eine formatierte Ausgabe (begrenzte Nachkommastellen) sinnvoll.\n",
"status" : "SUCCESS"
}
}