{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard.cost()` liefert immer 150 CHF, unabhängig davon, ob die Karte überhaupt benutzt/„geparkt“ wurde; damit wird beim Umsatz auch dann 150 CHF gezählt, wenn auf der FlatRateCard gar nie geparkt wurde (und es wird nicht klar, ob die 150 CHF pro Abrechnungsperiode nur einmal zählen sollen).\n- `FlatRateCard.reset()` macht nichts; wenn der Umsatz mehrmals nacheinander berechnet wird, ist nicht eindeutig, ob die Monatsgebühr erneut verrechnet werden soll oder nach einem Reset „verbraucht“ ist (dein Verhalten ist aktuell nicht konsistent mit dem Reset-Konzept der anderen Karten).\n- Der in der Aufgabenstellung geforderte Gesamtumsatz von **156.75 CHF** wird mit deinen Tarifen und den im Example verwendeten Parkzeiten nicht erreicht (bei dir kommt ein anderer Wert heraus), d.h. irgendwo stimmt die erwartete Abrechnungskombination noch nicht mit der Aufgabenanforderung überein.\n\n### Suggestion\n- Überlege dir bei der `FlatRateCard`, ob die Monatsgebühr **immer** in `cost()` zurückgegeben werden soll, oder ob sie nur dann zählen soll, wenn die Karte im betrachteten Zeitraum „aktiv“ war (z.B. sobald einmal `park(...)` aufgerufen wurde).\n- Kläre für dich die Semantik von `reset()`: Soll `reset()` bei einer FlatRateCard bewirken, dass nach der Umsatzberechnung die Monatsgebühr für die nächste Periode wieder „neu anfällt“, oder soll `reset()` sie im aktuellen Lauf „auf 0“ setzen? Implementiere dann entsprechend einen internen Zustand (z.B. ob schon verrechnet/aktiviert).\n- Rechne den erwarteten Output 156.75 CHF einmal von Hand mit den vorgegebenen Parkvorgängen durch und vergleiche das mit dem, was deine Implementationen jeweils berechnen; so findest du am schnellsten, welche Karte/Regel die Abweichung verursacht.\n\n### Code Style\n- In `GroupCard` sollte `HOURLY_RATE` nicht in ALL_CAPS heißen, wenn es kein `static final` Konstante ist; nenne es z.B. wie ein normales Feld (`hourlyRate`).\n- In `ParkingSystemExample` ist `import java.util.List;` unbenutzt und kann entfernt werden.\n- Einheitlichkeit: In `GroupCard` und `IndividualCard` verwendest du teils unterschiedliche Benennungs-/Konstanten-Patterns (Konstante vs. Feld) – besser konsistent halten.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `BacktrackingAlgorithm` ist die Schleifenbedingung `while (!figure.isGoalReached() && figure.pathAhead())` zu strikt: Sobald vorne kein Pfad ist (aber evtl. links/rechts einer), brichst du die Schleife ab und gehst direkt in den Rückzug – dadurch erkundest du Abzweigungen, die nicht “ahead” liegen, nicht zuverlässig.\n- Dein Backtracking macht nach dem rekursiven Aufruf `navigate(figure)` jeweils nur `turnLeft()` bzw. `turnRight()`, um “zurückzudrehen”, aber du stellst die Figur damit nicht sicher wieder in die ursprüngliche Orientierung relativ zum Hauptpfad (und schon gar nicht an die ursprüngliche Position), bevor du die nächste Richtung prüfst.\n- Der Rückweg am Ende (`turnRight()` zweimal und dann `counter`-mal `moveForward()`) setzt voraus, dass der Rückweg immer exakt die gleiche Anzahl Schritte möglich ist und dass du dabei nie in eine Sackgasse/Abzweigung geraten bist; nach den rekursiven Ausflügen stimmt `counter` aber nicht mehr zwingend zur aktuellen Position, was zu falschen Bewegungen oder `GameOver` führen kann.\n- Es gibt keine Strategie gegen erneutes Betreten bereits untersuchter Bereiche: In Labyrinthen mit Schleifen/mehreren Wegen kann das zu sehr tiefer Rekursion oder Endlossuchen führen (die Aufgabe verlangt einen allgemeinen Algorithmus für die letzten Levels).\n\n### Suggestion\n- Überlege dir, was ein Backtracking-Schritt genau bedeutet: Welche Information musst du dir merken, um nach dem Testen eines Abzweigs **sicher** wieder am Entscheidungspunkt zu stehen (Position *und* Blickrichtung), bevor du den nächsten Abzweig testest?\n- Prüfe, ob deine Hauptschleife wirklich alle möglichen nächsten Aktionen zulässt. Eine typische Struktur ist: “solange Ziel nicht erreicht: entscheide anhand von vorne/links/rechts, was du als Nächstes tust” – nicht “solange vorne frei ist”.\n- Dein `counter` zählt aktuell nur Vorwärtsbewegungen im aktuellen Aufruf, aber Rekursion verändert die Position ebenfalls. Denk darüber nach, wie du den Rückweg unabhängig davon korrekt ausführst (z.B. anhand der tatsächlich gemachten Moves oder anhand gespeicherter Zustände).\n- Um Zyklen zu vermeiden: Überlege, ob du (a) besuchte Zellen/States markieren kannst (z.B. Kombination aus `row/col/dir`) oder (b) ein “rechte-Hand/links-Hand-Regel + Markierung” oder (c) einen Stack von Kreuzungen nutzt, bei denen du dir merkst, welche Richtungen schon ausprobiert wurden.\n\n### Code Style\n- In `BacktrackingAlgorithm` ist `counter` als “Schritte seit Aufrufbeginn” schwer nachvollziehbar, weil er mit Rekursion interagiert; ein klarer benannter Mechanismus (z.B. “stepsTakenInThisFrame” vs. “global path stack”) würde die Lesbarkeit stark verbessern.\n- Die Rekursion `navigate(figure)` innerhalb von `navigate` ohne klaren Abbruch außer “Ziel erreicht” kann schnell unübersichtlich werden; kommentiere zumindest die Invarianten (wohin soll die Figur nach dem Return zeigen/stehen?).\n- Du hast sehr viel Template-Code (Figure, Labyrinth, GameOver, …) im Attempt mitgeliefert, obwohl nur deine Algorithmus-Klassen und die Änderung in `LabyrinthApp` relevant sind; das macht Reviews unnötig lang.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist die `main`-Methode als `void main()` deklariert; als Einstiegspunkt erwartet Java eine `public static void main(String[] args)`-Methode (sonst startet das Programm in der Regel nicht).\n- In `Coordinate` greifst du auf `SwissMap.TOP_LEFT.east` und `SwissMap.TOP_LEFT.north` zu, obwohl `east`/`north` in `Coordinate` `private` sind; das ist so nicht zugreifbar und führt zu einem Compile-Fehler.\n\n### Suggestion\n- Schau dir die Methodensignatur an, die die JVM als Startpunkt verwendet, und passe die `main`-Methode so an, dass sie wirklich als Programmstart erkannt wird.\n- Verwende in `Coordinate.toGuiX/toGuiY` nicht die privaten Felder eines anderen `Coordinate`-Objekts, sondern greife über die vorhandenen Getter auf die Werte zu (oder überlege dir eine andere erlaubte Zugriffsmöglichkeit).\n\n### Code Style\n- Die Flags `description`/`hovering` sollten `private` sein (Kapselung) und ggf. sprechender benannt werden (z.B. `showDescription`, `isHovering`).\n- In `ModeButton` sind `color1`/`color2` veränderlich; wenn sie konstant bleiben sollen, mach sie `private final` (und ggf. als Konstanten benennen).\n- In `ModeButton.draw` hast du viel duplizierte Logik (mehrfach `fillRect` + `drawString` mit ähnlichen Farbumschaltungen); das lässt sich gut reduzieren, indem du Farben/Text erst bestimmst und danach einmal zeichnest.\n- In `City.draw` setzt du die Farbe auf Weiß für den Text, aber nicht zurück; bei mehreren Komponenten kann das Seiteneffekte haben. Speichere/restore relevante GUI-Zustände konsistent (ähnlich wie du es bei `fontSize` schon machst).\n\n\n# Exercise: visualizer\n\n### Correctness\n- In `VisualizerApp` ist die `main`-Methode nicht `static` und hat keine Parameter; so wird sie von Java nicht als Programmeinstiegspunkt erkannt.\n- Beim Prozessor-Datensatz soll die „effektive Rechengeschwindigkeit“ (clockRate * cores) auf der y-Achse dargestellt werden und dafür eine logarithmische y-Achse verwendet werden; du nimmst den Logarithmus bereits in `Processor.getY()`, damit ist die Achse selbst nicht „logarithmisch“, sondern die Daten sind vor-transformiert (das ist nicht dasselbe wie eine log-Skalierung im Visualizer).\n- Für Prozessoren soll als x-Wert der Veröffentlichungsmonat aus Jahr+Monat kombiniert werden; deine Formel `year * 12 + month` wirkt so, als ob `month` 1–12 ist. Falls die CSV 0–11 verwendet, wäre das um 1 Monat verschoben.\n\n### Suggestion\n- Schau dir die genaue Signatur an, die Java für den Start erwartet (Klassenmethode, Rückgabetyp, Parameterliste) und passe `VisualizerApp.main` daran an.\n- Überlege, wo „logarithmische y-Achse“ konzeptionell hingehört: in die Datenpunkte (Transformation der Werte) oder in die Darstellung (Mapping von Datenraum → GUI-Koordinaten). Prüfe dann, welche Variante die Aufgabenstellung eher meint.\n- Kontrolliere im CSV (oder beim Laden), in welchem Bereich `month` liegt, und teste mit ein paar bekannten Datenpunkten, ob die zeitliche Reihenfolge/Positionierung stimmt.\n\n### Code Style\n- In `Visualizer` sind `DUMMY_DOUBLE` und `DUMMY_STRING` jetzt komplett obsolet; die Konstanten und die dazugehörigen TODO-Kommentare kannst du entfernen, um Verwirrung zu vermeiden.\n- Du nutzt `toString()` als Detailbeschreibung im UI. Das funktioniert, ist aber semantisch etwas „zweckentfremdet“; ein expliziter Methodenname im Interface (z.B. für Detailtext) wäre lesbarer, auch wenn es aktuell nicht gefordert ist.\n- In `Movie.toString()` wird das Budget einfach durch 1_000_000 geteilt (Integer-Division, da `budget` ein `long` ist). Das ist zwar nicht verboten, aber kann zu ungenauen/abgeschnittenen Angaben führen; wenn du Dezimalstellen willst, müsstest du bewusst in `double` umwandeln.\n",
"status" : "SUCCESS"
}
}