{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- In `FlatRateCard` wird die Monatsgebühr von 150 CHF immer voll verrechnet, auch wenn gar nicht geparkt wurde. Je nach Interpretation von „Monatskosten“ kann das den erwarteten Gesamtumsatz beeinflussen (das Beispiel erwartet einen sehr spezifischen Umsatzwert).\n\n### Suggestion\n- Überlege dir, wann genau die 150 CHF beim `FlatRateCard` anfallen sollen: bei jeder Umsatzberechnung immer, nur wenn im aktuellen Abrechnungszeitraum überhaupt geparkt wurde, oder z.B. nur einmal pro „Monat“ (d.h. eher als Zustand, der nach dem ersten Verrechnen/Reset nicht erneut zählt). Prüfe das, indem du den erwarteten Gesamtumsatz mit deinen Kartenkosten nachrechnest.\n\n3. Code Style:\n- In `ParkingSystem.java` ist `import javax.smartcardio.Card;` unbenutzt und thematisch irreführend; entfernen.\n- In `FlatRateCard` ist `totalTime` gespeichert, aber wird für `cost()` nicht verwendet; entweder konsequent nutzen oder weglassen, damit klar ist, warum der Zustand existiert.\n- In `GroupCard` sollte `HOURLY_RATE` als Konstante/Zustand deutlicher modelliert werden (z.B. `private final double hourlyRate;` statt veränderbarer Großbuchstaben-Variable), das erhöht Lesbarkeit und verhindert versehentliche Änderungen.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `LabyrinthApp.main` startest du die Schleife bei `level = 7`; die Aufgabe verlangt, dass der Algorithmus allgemein funktioniert und damit prinzipiell auch für alle Levels eingesetzt werden kann (nicht nur fürs letzte).\n- In `BacktrackingAlgorithm.navigate` setzt du `direction = 2` und kommentierst „Anpassen je nach Level“ – das widerspricht der Anforderung eines allgemeinen Algorithmus (keine levelabhängigen Anpassungen/Startwerte).\n- Dein `BacktrackingAlgorithm` merkt sich keine besuchten Positionen (z.B. über `row()/col()`), dadurch kann er in Schleifen geraten bzw. sehr lange laufen, anstatt zuverlässig jedes Labyrinth zu lösen.\n- Die Variable `direction` in `BacktrackingAlgorithm` wird zwar verändert, aber sie beeinflusst die Navigation nicht (die tatsächliche Orientierung steckt in `figure.dir()`); damit ist deine „Richtungslogik“ faktisch wirkungslos.\n\n### Suggestion\n- Lass den Algorithmus immer bei Level 1 laufen, um zu prüfen, ob er wirklich „allgemein“ ist; wenn du nur Level 7 startest, versteckst du Probleme, die vorher auftreten könnten.\n- Vermeide harte Startwerte/Level-Anpassungen: nutze die Orientierung, die die Figur bereits mitbringt (`figure.dir()`), oder arbeite ganz ohne eigene Richtungsvariable.\n- Überlege dir, wie man beim Backtracking verhindert, dass man immer wieder in dieselben Zyklen läuft: typischer Ansatz ist, Zustände wie „Position + Blickrichtung“ oder „Position“ als besucht zu markieren, und beim Rückweg entsprechend wieder freizugeben oder Alternativen zu wählen.\n- Wenn du eine eigene `direction`-Variable behalten willst: prüfe, ob sie wirklich mit `figure.turnLeft/Right()` konsistent ist (in deinem Kommentar steht z.B. eine andere Kodierung als im Framework), und vor allem: nutze sie dann auch für Entscheidungen – sonst kannst du sie weglassen.\n\n### Code Style\n- Du duplizierst sehr viele vorgegebene Dateien (Figure, Labyrinth, LabyrinthGame, …) in der Abgabe; üblich ist, nur die neu zu erstellenden Klassen bzw. geänderten Dateien abzugeben, sonst wird es unnötig unübersichtlich.\n- In `BacktrackingAlgorithm` ist `moveForward(Figure)` als Wrapper ohne Zusatznutzen eher überflüssig; entweder konsequent für alle Aktionen kapseln (für Symmetrie) oder direkt `figure.moveForward()` verwenden.\n- Der Kommentar zur Richtungs-Codierung (`0=Nord, 1=Ost, 2=Süd, 3=West`) passt nicht zur im Framework verwendeten Dir-Definition (dort ist `dir=0` nach Osten über `cos/sin`); solche widersprüchlichen Kommentare machen das Debugging schwer.\n\n\n# Exercise: swissmap\n\n### Correctness\n- Teil c) ist nicht vollständig umgesetzt: `Mountain` implementiert noch kein `Hoverable` (inkl. `getInteractiveArea`, `onMouseEnter`, `onMouseExit`) und zeigt beim Hovern keine Beschreibung an.\n- Teil d) fehlt komplett: Es gibt keine Klasse `ModeButton`, nichts wird als Button gezeichnet, und per Klick wird der Satellite-Mode der `SwissMap` nicht umgeschaltet.\n\n### Suggestion\n- Für `Mountain`: orientiere dich an deiner `City`/`Lake`-Implementierung: zusätzlicher Hover-Zustand (z.B. boolean), `getInteractiveArea(Gui)` passend zur Bildposition/-grösse und in `draw(...)` die Beschreibung nur anzeigen, wenn „hovered“ aktiv ist.\n- Für `ModeButton`: du brauchst ein eigenes Objekt, das gleichzeitig zeichnen kann und Mausereignisse bekommt (Hover + Click). Damit der Button den Kartenmodus umschalten kann, muss er irgendwie Zugriff auf dasselbe `SwissMap`-Objekt haben, das du dem `Gui` hinzugefügt hast (nicht ein neues Map-Objekt erzeugen).\n\n### Code Style\n- `InteractiveArea` ist unbenutzt und `contains(...)` liefert immer `false`; entweder entfernen oder korrekt implementieren und dann auch wirklich verwenden.\n- In `SwissMapApp` sind Imports wie `Component` unbenutzt; aufräumen, damit klar bleibt, was wirklich benötigt wird.\n- In `SwissMapApp` speicherst du die Map als `Drawable` (`Drawable map = new SwissMap();`). Für Teil d) ist es oft hilfreicher, die Referenz mit dem konkreten Typ zu halten, damit du (bzw. der Button) die Map-spezifischen Methoden direkt nutzen kannst.\n\n\n# Exercise: visualizer\n\n### Correctness\n- `Country` implementiert das `DataPoint`-Interface noch nicht, damit kannst du den Länder-Datensatz nicht wie gefordert im `Visualizer` anzeigen.\n- `Processor` implementiert das `DataPoint`-Interface noch nicht, damit kannst du den Prozessor-Datensatz nicht wie gefordert im `Visualizer` anzeigen.\n- In `VisualizerApp` visualisierst du nur Movies; die Aufgabe verlangt, dass du auch Countries und Processors (jeweils über die `main`-Methode umstellbar) integrierst und testen kannst.\n- Beim Prozessor-Datensatz fehlen dadurch auch die geforderten Besonderheiten (x = Jahr+Monat kombiniert, y = clockRate * cores und logarithmische y-Achse sowie passende Detail-Anzeige der Taktfrequenz-Einheit), weil der Datensatz aktuell gar nicht kompatibel gemacht wurde.\n\n### Suggestion\n- Für `Country`: Überlege dir, welche Felder aus `Country` auf die Achsen sollen (Literacy vs. GDP per capita) und welche Information im Hover als Label/Details/Group sinnvoll ist (Screenshots: Gruppierung typischerweise nach Region).\n- Für `Processor`: Leite für `getX()` einen Monats-Zeitwert aus Jahr und Monat ab (ein einzelner monoton steigender Zahlenwert) und für `getY()` eine “effective speed” aus Taktfrequenz und Cores.\n- Für die logarithmische y-Achse beim Prozessor-Plot: Schau dir an, an welcher Stelle im `Visualizer` die y-Werte in Bildschirmkoordinaten umgerechnet werden, und wie du dort (oder über die gelieferten y-Werte) eine Log-Skalierung erzwingen könntest, ohne die anderen Datensätze kaputt zu machen.\n- Für `VisualizerApp`: Baue dir eine einfache Umschaltmöglichkeit (z.B. durch Auskommentieren/Umstellen oder anhand von `args`), sodass du nacheinander `loadMovies()`, `loadCountries()` und `loadProcessors()` wirklich an `Visualizer` übergibst.\n\n### Code Style\n- In `Movie.getX()` steht der Kommentar `// Beispiel`; solche “Übungs-/Placeholder”-Kommentare besser entfernen, wenn es die finale Abgabe ist.\n- Die Javadoc im Interface ist sehr kurz gehalten; die Aufgabe verlangt eine Dokumentation des *erwarteten Verhaltens* (z.B. was `getGroup()` bei “keine Gruppe” bedeutet, ob `getDetails()` mehrzeilig sein darf/soll, Einheiten/Formatierung).\n",
"status" : "SUCCESS"
}
}