{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n\n\n### Suggestion\n\n\n### Code Style\n- In den Fehlermeldungen mischst du Deutsch/Englisch („Street“, „City“, „ZipCode“); einheitliche Bezeichnungen machen die API/Exceptions leichter verständlich.\n- Die Invarianten-Checks sind aktuell in den Settern dupliziert (Street/City sehr ähnlich); falls ihr im Kurs Wert auf DRY legt, könntest du Validierung ggf. in private Hilfsmethoden auslagern (ohne Logik zu ändern).\n\n\n# Exercise: timespan\n\n### Correctness\n- Im Konstruktor fehlt eine explizite Precondition dafür, dass die initiale Zeitspanne insgesamt nicht negativ ist (`totalMinutes >= 0`). Mit deiner aktuellen Logik sind z.B. `hours = -1, minutes = 30` zwar insgesamt negativ (−30 Minuten), werden aber nicht abgefangen, weil du nur einzelne Parameter auf Negativität prüfst.\n\n### Suggestion\n- Überlege bei den Preconditions nicht nur „sind `hours` und `minutes` einzeln ≥ 0“, sondern „ist die daraus entstehende Gesamtzeitspanne ≥ 0“. Das gilt besonders im Konstruktor, weil dort der Anfangszustand die erste Invariante erfüllen muss. Eine robuste Prüfung lässt sich über eine Berechnung in Minuten ausdrücken (ohne dass ich dir hier die genaue Codezeile vorgebe).\n\n### Code Style\n- Dein `toString()` ist zwar hilfreich, ist aber in der vorgegebenen Exercise-Code-Version nicht enthalten; falls Tests strikt auf die API prüfen, könnte das je nach Setup unerwartet sein.\n\n\n# Exercise: asteroids\n\n### Correctness\n- In `AsteroidsGame` fehlt ein echtes Java-Entry-Point `public static void main(String[] args)`, stattdessen gibt es nur `void main()`. So startet das Programm nicht wie erwartet.\n- Die Anforderung „definiere eine Klasseninvariante“ für den Falcon ist nicht wirklich umgesetzt: Du begrenzt die Position zwar in `move()`, aber eine Invariante bedeutet, dass die Einschränkung als Bedingung gilt/überprüft wird (z.B. als assert/check), nicht nur „nachträglich korrigiert“.\n- Beim Game-Over-Zustand wird der Hintergrund/letzte Frame nicht mehr gezeichnet; du zeichnest nur das `game-over.png` und machst direkt `refreshAndClear(20)`. Dadurch ist das Game-Over-Bild ggf. nur sehr kurz sichtbar bzw. wird gleich wieder gecleart (und es fehlt der Kontext des Spielfelds).\n\n### Suggestion\n- Schau dir an, wie Java Programme üblicherweise gestartet werden: Welche Methodensignatur erwartet die JVM als Einstiegspunkt, und wie rufst du dann deine Spiel-Loop-Methode auf?\n- Überlege, wie du die Spielfeld-Grenzen als echte Klasseninvariante ausdrücken kannst: Wo würdest du die Bedingung platzieren, damit klar ist „dies muss immer gelten“, und nicht nur „ich fixe es, wenn es passiert“?\n- Für Game-Over: Denke in Frames. Was muss im letzten Frame alles gezeichnet werden, bevor du refreshst? Und wann darfst du überhaupt `clear` machen, wenn das Game-Over-Bild stehen bleiben soll?\n\n### Code Style\n- Die `[cite: ...]` Kommentare wirken wie Artefakte aus einem Tool/Editor und gehören normalerweise nicht in Abgaben; entferne sie, damit der Code sauber bleibt.\n- `baseRadius` in `Asteroid` sollte als `static final` Konstante (und typischerweise großgeschrieben) modelliert werden, da er nicht pro Objekt variieren muss.\n- In `updateAsteroids()` sind „Magic Numbers“ wie `30`, `-50`, `+100`, Geschwindigkeitsbereiche etc. direkt im Code; als benannte Konstanten werden sie leichter verständlich und anpassbar.\n\n\n# Exercise: bosses\n\n### Correctness\n\n### Suggestion\n\n### Code Style\n- In `isSuperiorOf`, du greifst direkt auf `current.boss` zu; konsistenter (und kapselungsfreundlicher) wäre es, überall über `getBoss()` zu gehen, statt innerhalb der Klasse mal Feldzugriff und mal Getter zu mischen.\n- `findCommonSuperiorWith` nutzt `isSuperiorOf` in einer Schleife und läuft damit potentiell mehrfach die Boss-Kette ab; das ist zwar korrekt, aber kann bei langen Hierarchien unnötig teuer werden (quadratisches Verhalten).\n\n\n# Exercise: smarthome\n\n### Correctness\n- Du hast die Klasse `Room` gegenüber der Vorlage so geändert, dass sie intern eine `ArrayList<Lamp>` statt `Lamp[]` verwendet; damit verletzt du die vorgegebene Schnittstelle/Struktur der Übung (und riskierst Inkompatibilitäten mit erwartetem Code/Tests), auch wenn `getLamps()` wieder ein Array liefert.\n- In `Room.getLamps()` erzeugst du bei jedem Aufruf ein neues Array; dadurch arbeiten deine Methoden in `Home` auf Kopien der Lampen-Array-Struktur (nicht auf dem originalen Array aus `Room`). Das ist zwar bei Lampenobjekten oft “zufällig” noch ok (weil die Lampenobjekte selbst gleich bleiben), aber es weicht vom Modell “Room besitzt ein Lamp[]” ab und kann zu unerwartetem Verhalten führen, wenn irgendwo erwartet wird, dass es immer dasselbe Array ist.\n\n### Suggestion\n- Lass `Room` so, wie es in der Aufgabe vorgegeben ist (Felder `private final Lamp[] lamps;`, `getLamps()` gibt dieses Array direkt zurück), und verschiebe allfällige Zusatzlogik (z.B. Verbrauch berechnen) so, dass du dafür keine Änderung der Datenstruktur brauchst.\n- Überlege dir bei `getLamps()`: Wenn du jedes Mal ein neues Array erzeugst, welche Teile des Programms könnten dann “das Array” verändern wollen (z.B. Lampenreihenfolge, Referenzen vergleichen, etc.) und was passiert dann? Richte deine Implementierung so aus, dass sie das erwartete Objektmodell der Vorlage beibehält.\n\n### Code Style\n- In `Room.java` hast du zusätzliche Imports (`List`) die nicht verwendet werden.\n- `getActualPowerConsumption()` und die Umstellung auf `ArrayList` sind nicht Teil der Aufgabe und blähen die Lösung unnötig auf; halte dich möglichst eng an die Vorlage, damit Korrektur/Tests einfacher bleiben.\n- In `getActualPowerConsumption()` mischst du `var` und Iterator-Logik; in diesem Kurskontext wäre eine einfache for-each-Schleife meist lesbarer (und näher am behandelten Stoff).\n",
"status" : "SUCCESS"
}
}