{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- Die Klasse heißt bei dir `FlatRateCart`, gefordert ist aber `FlatRateCard` (und im Beispielcode wird auch `new FlatRateCard()` verwendet). So wie es jetzt ist, passt es nicht zur Aufgabenstellung und zum vorgegebenen Beispiel.\n- `FlatRateCart.cost()` gibt immer 150 zurück, unabhängig davon, ob geparkt wurde oder nicht. Damit wird der erwartete Gesamtumsatz (156.75 CHF) mit deinem Example-Ablauf nicht erreicht (du würdest zusätzlich immer 150 CHF einrechnen).\n- In `ParkingSystemExample` ist zusätzlicher Code mit `List.of(...)` enthalten, der zur Aufgabe nicht gehört und außerdem zur Laufzeit fehlschlägt (`List.of` ist unveränderlich, `add` wirft eine Exception). Damit läuft das Programm nicht wie gefordert durch bis zur Umsatz-Ausgabe.\n\n### Suggestion\n- Prüfe, ob Klassenname/Dateiname/Verwendung im Example exakt mit der Aufgabenbeschreibung übereinstimmen (insbesondere `FlatRateCard` vs. `FlatRateCart`).\n- Überlege bei der Flat-Rate-Karte: Wann genau sollen die 150 CHF in die Abrechnung einfließen? Vergleiche das mit dem Beispielablauf (Parkzeiten) und dem erwarteten Gesamtumsatz 156.75 CHF – daraus kannst du ableiten, wie `cost()` sich verhalten muss.\n- Entferne den fremden `List`-Teil komplett aus `ParkingSystemExample`, sodass dein Programm nur das Parking-System demonstriert und ohne Exception durchläuft.\n\n### Code Style\n- In `GroupCard` sollten Felder wie `noOfPeople`, `HOURLY_RATE` und `totalTime` gekapselt werden (`private`) und Konstanten/konzeptuelle Konstanten konsistent benannt werden (`hourlyRate` als normales Feld vs. `HOURLY_RATE` als `static final`).\n- `GroupCard`-Konstruktor hat keine Sichtbarkeit (package-private). Wenn die Karten auch außerhalb des Packages erzeugt werden sollen (typisch bei solchen Aufgaben), nimm eine explizite Sichtbarkeit (meist `public`).\n- In `ParkingSystemExample` ist `import java.util.List;` und der komplette Colors-Block unbenutzt bzw. themenfremd und sollte raus, um die Aufgabe fokussiert zu halten.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- Dein `BacktrackingAlgorithm` macht inhaltlich kein Backtracking, sondern folgt einer festen Priorität (links, geradeaus, rechts, sonst umdrehen). Das erfüllt die Anforderung „allgemeiner Algorithmus für alle Labyrinthe“ nicht zuverlässig, weil du keine Sackgassen systematisch „merkst“ und alternative Abzweigungen später gezielt ausprobierst.\n- Durch das fehlende Merken von besuchten Zuständen/Entscheidungspunkten kann dein Algorithmus in Schleifen geraten (z. B. im Kreis laufen) und damit das Ziel ggf. nie erreichen, obwohl ein Weg existiert.\n- In `LabyrinthApp` ist `main()` als `void main()` deklariert. Falls die Aufgabe vorsieht, dass das Programm direkt startbar ist, braucht es üblicherweise eine echte Java-Entry-Point-Signatur (sonst wird es ggf. nicht ausgeführt).\n\n### Suggestion\n- Überlege dir, was „Backtracking“ konkret bedeutet: An Kreuzungen musst du dir merken, welche Optionen du schon ausprobiert hast, und wenn du in einer Sackgasse landest, gezielt zur letzten offenen Kreuzung zurückkehren und dort die nächste Option nehmen.\n- Prüfe, wie du Zustände der Figur identifizieren kannst (Position + Blickrichtung) und wie du verhindern kannst, dass du denselben Zustand unendlich oft wieder betrittst; das kann dir helfen, Loops zu vermeiden.\n- Schau dir an, an welchen Stellen du „Entscheidungen“ triffst (mehr als ein möglicher Weg) und wie du diese Entscheidungen auf einem Stack/Verlauf speichern könntest, um später dorthin zurückzugehen.\n- Kontrolliere die erwartete Signatur der `main`-Methode in der Vorlage/Aufgabenstellung; oft ist das der Grund, warum beim Ausführen „nichts passiert“.\n\n### Code Style\n- In deiner Abgabe sind sehr viele Template-Klassen (z. B. `Figure`, `Labyrinth`, `LabyrinthGame`, `GameOver`) erneut enthalten; normalerweise reicht es, nur die neuen/angepassten Klassen abzugeben, damit die Abgabe übersichtlich bleibt (sofern nicht explizit gefordert).\n- `BacktrackingAlgorithm` ist vom Namen her irreführend, weil die Logik aktuell eher „Left-hand-rule/Try-left-first“ ist; ein passenderer Name oder ein Kommentar zur Strategie würde Missverständnisse vermeiden.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist `main()` nicht als `public static void main(String[] args)` deklariert; so wird die Applikation typischerweise nicht als Java-Programm startbar sein (je nach Testumgebung wird genau diese Signatur erwartet).\n- In `City.draw(...)` zeichnest du den Punkt mit `fillCircle(...)`, ohne vorher eine Farbe zu setzen; falls die Standardfarbe nicht passt (oder von vorherigen Komponenten “mitgenommen” wird), kann die Darstellung nicht wie beabsichtigt sein.\n\n### Suggestion\n- Prüfe, welche `main`-Signatur Java als Einstiegspunkt verlangt und welche die Aufgabe/Projektvorlage erwartet; passe die Methodendeklaration entsprechend an.\n- Setze in `draw(...)` der `City` vor dem Zeichnen explizit eine Farbe (und ggf. danach wieder zurück), damit die Darstellung unabhängig von anderen Komponenten stabil bleibt.\n\n### Code Style\n- `volatile` für deine `description`-Flags (und auch für die `Color`-Felder im `ModeButton`) wirkt hier eher unnötig; das macht den Code schwerer lesbar, ohne klaren Nutzen in dieser GUI-Übung.\n- In `ModeButton` sind `color1`/`color2` veränderlich und werden per Swap getauscht; lesbarer wäre ein klarer “hovered”-Zustand (bool) und die Farben davon abgeleitet, statt Werte hin- und herzutauschen.\n- In mehreren `draw(...)`-Methoden setzt du Font/Bold, aber stellst es nicht wieder zurück; das kann Seiteneffekte auf andere Komponenten haben.\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 hier problematisch, weil `toString()` bereits von `Object` kommt und in einem Interface in dieser Form typischerweise nicht als Teil der fachlichen Schnittstelle verlangt/gedacht ist (der Visualizer braucht eher eine “Detailbeschreibung” als bewusst `toString` als Vertrag).\n- In `Processor.toString()` wird bei GHz-Ausgabe nicht wie gefordert formatiert: GHz-Werte sollen als Kommazahlen “geeignet” angezeigt werden (z. B. 2.5 GHz). Bei dir kann z. B. `2500000 kHz` zu `2.5GHz` werden, aber ohne definierte Rundung/Formatierung und ohne Leerzeichen vor der Einheit; außerdem werden MHz/kHz ohne Leerzeichen/Einheitstrennung ausgegeben, was nicht dem Screenshot-/Textziel entspricht.\n- In `Processor.getX()` kombinierst du `year * 12 + month`; wenn `month` im Datensatz als 1–12 vorliegt, ist das ok, aber falls es 0–11 ist, verschiebt sich alles um einen Monat. Die Aufgabe verlangt “Jahr und Monat zu einem einzigen Wert kombinieren” – das sollte eindeutig und konsistent zur Datensatzdefinition sein.\n\n### Suggestion\n- Schau dir die Aufgabenformulierung zu “Dokumentiere das erwartete Verhalten … mit Javadoc” an und ergänze für jede Methode im Interface kurz: was bedeutet x/y, was ist der Name, was ist die Gruppe, was soll in der Detailansicht erscheinen.\n- Überlege, ob du statt `toString()` als “Detailtext”-Vertrag lieber eine dedizierte Methode im Interface brauchst (und im Visualizer dann diese nutzt). So vermeidest du die Vermischung mit `Object.toString()` und machst die Schnittstelle klarer.\n- Für die Prozessor-Taktfrequenz: teste ein paar konkrete `clockRateKhz`-Werte (z. B. 800000, 2500000, 999) und prüfe, ob dein String wirklich wie in der Aufgabenbeschreibung wirkt (Einheit, Rundung, Ganzzahl vs. Kommazahl, Lesbarkeit).\n- Prüfe im CSV bzw. beim Einlesen, wie `month` kodiert ist, und entscheide dann, ob du beim Kombinieren `month` direkt nehmen kannst oder ob eine Anpassung nötig ist (z. B. damit Januar und Dezember korrekt im Zeitstrahl liegen).\n\n### Code Style\n- Unnötiger Import in `DataPoint`: `ch.trick17.gui.component.Hoverable` wird nicht verwendet.\n- `toString()` im Interface ist verwirrend, weil es wie eine Override-Deklaration wirkt; selbst wenn es kompiliert, ist es als API-Design schwerer verständlich als eine klar benannte Methode (z. B. “detailsText” o. ä.).\n- In `Country`, `Movie`, `Processor` fehlen `@Override`-Annotationen bei implementierten Interface-Methoden (`getX`, `getY`, `getGroup`, `getName`, `toString`) – das hilft, Tippfehler früh zu finden.\n- In `Processor.toString()` wäre konsistente Formatierung (Leerzeichen vor Einheiten, ggf. `String.format`) deutlich lesbarer als String-Konkatenation mit “GHz/MHz/kHz” direkt angehängt.\n",
"status" : "SUCCESS"
}
}