{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard` ist in deinem Code als `FlatRateCart` benannt (Dateiname/Klasse) und wird auch so verwendet; die Aufgabe verlangt aber explizit eine Klasse `FlatRateCard` (sonst passt auch das Beispiel `new FlatRateCard()` nicht).\n- In `ParkingSystemExample` enthält dein Code zusätzliche Anweisungen mit `List.of(...)` und anschließendem `colors.add(\"Yellow\")`; das führt zur Laufzeit zu einer `UnsupportedOperationException` und verhindert, dass das Programm wie gefordert sauber läuft und den Umsatz ausgibt.\n\n### Suggestion\n- Achte darauf, dass Klassenname, Dateiname und der im Beispiel erwartete Name exakt übereinstimmen (insbesondere bei `FlatRateCard`), sonst scheitern Tests/Autograding oft schon am Typnamen.\n- Entferne oder korrigiere den Teil mit der unveränderlichen Liste, sodass dein Beispielprogramm ohne Exception bis zur Umsatz-Ausgabe durchläuft.\n\n### Code Style\n- In `GroupCard` sollten Felder wie `noOfPeople`, `HOURLY_RATE` und `totalTime` sinnvoll gekapselt sein (typisch: `private`, und Konstanten eher `final`/konstant benannt).\n- In `GroupCard` ist `HOURLY_RATE` als Feldname in ALLCAPS irreführend, weil es je nach Konstruktorparameter variiert (das wirkt wie eine Konstante).\n- In `ParkingSystemExample` ist `import java.util.List;` nur wegen des zusätzlichen Demo-Codes da; sobald du den entfernst, ist der Import überflüssig.\n- In `FlatRateCart.park()` und `reset()` sind leere Methoden ok, aber ein kurzer Kommentar, warum sie leer sind (Flatrate), macht das Verhalten verständlicher.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- Dein `BacktrackingAlgorithm` ist inhaltlich kein Backtracking, sondern im Wesentlichen eine „Left-hand-rule“/Prioritätsregel (links > gerade > rechts > umdrehen). Damit ist nicht garantiert, dass du die letzten Levels (bzw. alle Labyrinthe allgemein) löst, wie in der Aufgabe gefordert.\n- In `LabyrinthApp` verwendest du direkt `new BacktrackingAlgorithm()` für alle Levels. Die Aufgabe verlangt aber explizit auch die Implementierung und den Einsatz von `StupidAlgorithm` (für Level 1) sowie `TryStraightFirst` (für die ersten vier Levels) – also diese Schritte/Algorithmen sind zwar als Klassen vorhanden, werden aber in der App nicht wie gefordert nacheinander eingesetzt.\n\n### Suggestion\n- Überlege beim „Backtracking“-Teil, wie du erkennst, dass du in eine Sackgasse gelaufen bist *und* wie du dann gezielt zu einer früheren Verzweigung zurückkehrst, um einen anderen noch nicht ausprobierten Weg zu testen (statt nur nach einer festen Priorität abzubiegen).\n- Denk darüber nach, welche Zusatzinformation du dir während des Laufens merken musst (z.B. besuchte Kreuzungen, Entscheidungen, oder Richtungen), damit „zurückgehen und Alternative probieren“ überhaupt möglich wird.\n- Für `LabyrinthApp`: prüfe die Aufgabenbeschreibung Schritt für Schritt und setze testweise wirklich zuerst den dummen Algorithmus ein, dann den zweiten – und erst danach den finalen Algorithmus (oder ermögliche leichtes Umschalten), damit du die Anforderungen sichtbar erfüllst.\n\n### Code Style\n- In `BacktrackingAlgorithm` und `TryStraightFirst` wiederholt sich Code (z.B. „umdrehen“ = zweimal `turnRight()`, dann `moveForward()`). Das könntest du als kleine Hilfsmethode kapseln, damit es lesbarer wird und weniger Copy/Paste hat.\n- Du hast sehr viele Dateien aus der Vorlage (Figure, Labyrinth, GameOver, LabyrinthGame, NaviAlgorithm) im Attempt erneut aufgeführt. Falls das im Abgabe-Setup nicht nötig ist, lenkt es ab und erhöht das Risiko von unbeabsichtigten Abweichungen zur Vorlage.\n\n\n# Exercise: swissmap\n\n### Correctness\n- Die `main`-Methode in `SwissMapApp` hat die falsche Signatur (`void main()` statt `public static void main(String[] args)`); so wird das Programm i. d. R. nicht als Java-Startpunkt erkannt und läuft nicht wie gefordert über die normale Main-Methode.\n\n### Suggestion\n- Prüfe, wie eine Java-Applikation gestartet wird (Entry Point) und passe die Methodensignatur so an, dass die JVM sie automatisch findet; achte dabei auf `static`, `public` und den Parameter-Typ.\n\n### Code Style\n- `volatile` für die `description`-Flags und die Farben im `ModeButton` ist sehr wahrscheinlich unnötig (GUI-Loop läuft typischerweise in einem Thread); das macht den Code ohne Nutzen komplexer.\n- In `ModeButton` sind `color1`/`color2` nicht wirklich “Konstanten”, werden aber wie Zustandsvariablen herumgetauscht; lesbarer wäre ein klarer Hover-Zustand (boolean) und Farben abhängig davon (ohne Swapping).\n- In `City.draw()` setzt du Font/Bold nur im Hover-Fall, aber setzt nie zurück; wenn die GUI-API Zustände beibehält, kann das unbeabsichtigt andere Komponenten beeinflussen (bei Seen/Bergen ebenso).\n\n\n# Exercise: visualizer\n\n### Correctness\n- In `VisualizerApp` ist `main()` nicht `static` und hat keinen `String[] args`-Parameter; so wird das Programm in der üblichen Java-Ausführung nicht als Einstiegspunkt erkannt.\n- Beim Prozessor-Datensatz soll für die x-Achse der Veröffentlichungsmonat aus *Jahr und Monat* kombiniert werden; deine Berechnung `year * 12 + month` ist sehr wahrscheinlich um 1 Monat verschoben (weil Monate typischerweise 1–12 sind).\n- Die Detailbeschreibung beim Prozessor-Datensatz soll die Taktfrequenz in kHz/MHz als ganze Zahl und in GHz als Kommazahl anzeigen; bei dir kann der GHz-Fall sehr viele Dezimalstellen ausgeben und es fehlt jeweils ein Leerzeichen vor der Einheit (z. B. `800MHz` statt `800 MHz`).\n\n### Suggestion\n- Schau dir die exakte Methodensignatur an, die die JVM als Programmeinstieg erwartet, und passe deine `main`-Methode daran an (Stichworte: `public`, `static`, Parameter).\n- Überlege beim Kombinieren von Jahr+Monat für `getX()`: Wenn Januar der erste Monat ist, welche fortlaufende Monatszahl sollte Januar eines Jahres bekommen? Teste das mit einem kleinen Beispiel (z. B. 2020/1 und 2020/12) und prüfe, ob der Abstand genau 11 Monate ist.\n- Für die Prozessor-Detailanzeige: Formatiere den GHz-Wert auf eine sinnvolle Anzahl Nachkommastellen (z. B. eine) und achte darauf, dass die Einheiten genau wie gefordert erscheinen (inkl. Leerzeichen und Ganzzahl-/Dezimaldarstellung je nach Einheit).\n\n### Code Style\n- In `DataPoint` ist der Import `ch.trick17.gui.component.Hoverable` unbenutzt und sollte entfernt werden.\n- Ein Interface muss `toString()` nicht deklarieren (kommt von `Object`); das kann verwirrend sein. Besser wäre eine klar benannte Methode für die Detailzeilen (z. B. “details”/“tooltip” o. ä.), statt `toString()` als Teil des Contracts zu “erzwingen”.\n- In `Visualizer` sind `DUMMY_DOUBLE` und `DUMMY_STRING` jetzt unbenutzt; nachdem du alles ersetzt hast, kannst du die Konstanten und die TODO-Kommentare entfernen, damit der Code aufgeräumt bleibt.\n",
"status" : "SUCCESS"
}
}