{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard.cost()` ist nicht gemäss Aufgabe: Die Monatskosten sollen fix 150 CHF sein (nicht abhängig davon, ob überhaupt geparkt wurde).\n- `ParkingSystemExample` enthält zusätzlichen Code mit `List.of(...)` und `colors.add(\"Yellow\")`, was zur Laufzeit eine `UnsupportedOperationException` wirft; damit läuft das Beispielprogramm nicht sauber durch (Anforderung: Programm soll laufen und den Umsatz ausgeben).\n\n### Suggestion\n- Überlege bei `FlatRateCard`, was “fixe Monatskosten von 150 CHF” konkret bedeutet: Soll die Karte auch dann 150 CHF liefern, wenn nie `park(...)` aufgerufen wurde?\n- Entferne oder ändere den `List.of(...)`-Teil im Example so, dass das Beispielprogramm ohne Exception bis zur Umsatz-Ausgabe durchläuft (oder lass diesen Teil komplett weg, weil er nicht zur Aufgabe gehört).\n\n### Code Style\n- In `GroupCard` sind `HOURLY_RATE`, `noOfPeople` und `totalTime` package-private; mach Felder typischerweise `private` (und Konstanten eher `private final` bzw. `static final`, je nach Design).\n- `GroupCard(int noOfPeople)` hat keinen `public`-Modifier; falls die Klasse auch von ausserhalb des Packages genutzt werden soll, wäre ein `public`-Konstruktor sinnvoll.\n- In `IndividualCard` fehlen die `@Override`-Annotationen bei den Interface-Methoden; das hilft beim Vermeiden von Tippfehlern.\n- `ParkingSystemExample` hat ein unbenutztes `import java.util.List;` für aufgabenfremden Code; generell aufgabenfremde/unbenutzte Teile entfernen.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- Dein `BacktrackingAlgorithm` ist kein echtes Backtracking: Du speicherst keine Entscheidungspunkte/Verzweigungen und gehst auch nicht gezielt zu einem früheren Knoten zurück, wenn ein Weg eine Sackgasse/Schleife ist; damit ist nicht garantiert, dass du die “letzten Levels” zuverlässig schaffst.\n- In `BacktrackingAlgorithm` kann die Logik in manchen Labyrinthen in Endlosschleifen laufen (z.B. im Kreis), weil du keine “besucht”-Information bzw. keine Rücksprungstrategie hast, die sicherstellt, dass du nicht immer wieder dieselben Zustände abläufst.\n\n### Suggestion\n- Überlege dir, was “Backtracking” im Kontext eines Labyrinths konkret bedeutet: Welche Information brauchst du, um an einer Kreuzung später wieder “zurück” zu können und dann einen anderen Abzweiger zu testen?\n- Denk in “Zuständen”: Wenn du schon mal an Position (row, col) mit einer bestimmten Richtung warst und danach wieder genau dort/dorthin kommst, wie erkennst du das und wie verhinderst du, dass du wieder dasselbe machst?\n- Ein hilfreicher Ansatz ist, an Verzweigungen eine Art “Stack”/Liste zu führen (Entscheidungen merken) und bei Sackgassen die Schritte/Turns rückgängig zu machen bzw. gezielt zum letzten offenen Knoten zurückzugehen.\n\n### Code Style\n- In `BacktrackingAlgorithm` und `TryStraightFirst` steckt sehr ähnliche Logik (Reihenfolge der Checks + “U-Turn”); wenn mehrere Algorithmen Varianten davon sind, könntest du gemeinsame Hilfsfunktionen extrahieren, um Duplikation zu reduzieren.\n- In deinen Algorithmus-Klassen könntest du jeweils `@Override` über `navigate` setzen, damit der Compiler dich bei Signaturfehlern besser unterstützt.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist die `main`-Methode nicht als Java-Entry-Point deklariert (sie ist weder `public` noch `static` und hat keinen `String[] args`-Parameter); so startet das Programm typischerweise nicht über “Run”.\n- In `City.draw` wird vor dem `fillCircle` keine Farbe gesetzt; je nach Default-Zustand der GUI kann die Stadt-Markierung dadurch unsichtbar/unerwartet dargestellt werden (Anforderung: Objekte sollen sichtbar angezeigt werden).\n\n### Suggestion\n- Schau dir die erwartete Signatur für eine Java-`main`-Methode an und passe sie so an, dass deine App als Einstiegspunkt erkannt wird.\n- Setze in `draw` für die City (und ggf. für andere Elemente) explizit eine passende Zeichenfarbe, bevor du etwas füllst/zeichnest, damit die Darstellung unabhängig von vorherigen Komponenten zuverlässig ist.\n\n### Code Style\n- Die Felder `description`/`hovering` sollten `private` sein (Kapselung) und sinnvoll benannt werden (z.B. etwas wie `showDescription`), damit klar ist, was der Boolean bedeutet.\n- In `ModeButton` sind `color1`/`color2` veränderlich; wenn sie konstant sind, mach sie `private final`, um unbeabsichtigte Änderungen zu verhindern.\n- In `ModeButton.draw` steckt viel duplizierte Logik (fast gleiche Blöcke für Hover/Nicht-Hover und Modus); das lässt sich durch Zwischencolors/Text-Variablen deutlich vereinfachen und lesbarer machen.\n- In `City`, `Lake`, `Mountain` wiederholt sich Hover-Logik und Font-State-Sicherung stark; überlege, ob du gemeinsame Hilfsmethoden/konstante Werte (z.B. Icon-Grössen, Offsets) zentralisieren willst.\n\n\n# Exercise: visualizer\n\n### Correctness\n- In `Country`: Die x/y-Zuordnung ist gemäss Aufgabenbeschreibung vertauscht (x soll *literacy*, y soll *GDP per capita* sein). Du gibst zwar `getX()` als literacy zurück, aber `getY()` ist GDP/capita – das passt; allerdings ist deine `toString()`-Detailzeile inhaltlich umgekehrt formuliert (zeigt literacy dann GDP/capita – ok), aber prüfe v. a. ob die Achsen in der Visualisierung wirklich wie gefordert interpretiert werden (x=unabhängig, y=abhängig).\n- In `Processor`: Für die y-Achse soll laut Aufgabenbeschreibung die *effektive Rechengeschwindigkeit* als `clockRate * cores` verwendet werden und **die y-Achse soll logarithmisch dargestellt werden**. Du nimmst stattdessen `log10(clockRateKhz * cores)` als Datenwert. Damit ist nicht mehr die Achse logarithmisch, sondern die Daten sind bereits transformiert.\n- In `VisualizerApp`: Die `main`-Methode ist als `void main()` deklariert. Für das Starten als Java-Programm wird üblicherweise eine `public static void main(String[] args)` Signatur erwartet (je nach Projektsetup/IDE kann das sonst nicht als Einstiegspunkt erkannt werden).\n\n### Suggestion\n- Für die Länder: Überlege dir, was der Visualizer als x bzw. y wirklich darstellt (deine `getX()/getY()`-Methoden) und gleiche das nochmals explizit mit dem Text “Einfluss der Lesefähigkeit auf GDP/capita” ab, damit x wirklich literacy und y wirklich GDP/capita ist.\n- Für die Prozessoren: Entscheide dich für **eine** Stelle für die Log-Skalierung: entweder Rohwerte liefern (clockRate*cores) und die Darstellung logarithmisch machen, oder (wenn der Visualizer keine Log-Achse kann) zumindest sicherstellen, dass das verlangte Verhalten “logarithmische y-Achse” erfüllt ist. Schau dazu, wo im Visualizer die Koordinaten skaliert werden (`guiY`/`findMinMax`) und ob dort eine Logik sinnvoll wäre.\n- Für `VisualizerApp`: Prüfe, ob deine Umgebung die Methode `void main()` überhaupt als Programmeinstieg akzeptiert. Falls nicht: vergleiche die geforderte Signatur eines Java-Einstiegspunkts mit deiner und passe sie entsprechend an.\n\n### Code Style\n- In `DataPoint`-Javadocs sind die Beschreibungen sehr kurz; die Aufgabe verlangt das “erwartete Verhalten” zu dokumentieren. Es hilft, genauer zu beschreiben (z.B. Wertebereich/Einheit, ob `getGroup()` `null` liefern darf, und was `getName()`/Detailtext enthalten soll).\n- Du überschreibst `toString()` als Detailtext-Quelle: Das funktioniert, ist aber semantisch etwas “zweckentfremdet” (toString eher für Debugging). Eine eigene Methode im Interface (z.B. für Detailzeilen) wäre oft klarer; falls ihr aber beim Vorgegebenen bleiben wollt, dann zumindest konsistent bei allen Klassen.\n- In `Processor.toString()`: Die Einheitenformatierung ist etwas uneinheitlich (z.B. fehlendes Leerzeichen vor “GHz/MHz/kHz”, Rundung auf 2 Nachkommastellen auch wenn .00). Das ist nicht falsch, aber macht die Anzeige weniger lesbar.\n",
"status" : "SUCCESS"
}
}