{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n\n### Suggestion\n\n### Code Style\n- Die Fehlermeldungen in den `IllegalArgumentException`s sind auf Englisch; je nach Kurs-/Projektvorgaben könnte eine einheitliche Sprache (z.B. Deutsch) erwartet sein.\n- In `format()` greifst du direkt auf die Felder zu; zur besseren Kapselung könntest du konsistent die Getter verwenden (so bleibt das Verhalten gleich, falls sich Validierungs-/Normalisierungslogik später ändert).\n\n\n# Exercise: timespan\n\n### Correctness\n- In `add(int hours, int minutes)` fehlt die geforderte Precondition, dass `totalMinutes` nach dem Aufruf **nicht kleiner** sein darf als vorher (Zeitspanne darf nicht verkürzt werden). Mit deinem aktuellen `requireNonNegative` kann der Client z.B. `add(0, -5)` nicht, aber `add(-1, 0)` wird bereits abgefangen – allerdings könntest du immer noch durch Kombinationen, die insgesamt negativ wären, gar nicht erst reinkommen; die Anforderung ist dennoch explizit: es soll eine Prüfung auf “Verkürzen” bezogen auf die gesamte Zeitspanne geben, nicht nur auf Nicht-Negativität der Parameter.\n- Die Invariante `totalMinutes >= 0` ist aus Client-Sicht formuliert. Mit `normalize()` kann bei Eingaben wie `hours = 0, minutes = 0` alles ok sein, aber du solltest sicherstellen, dass es **keinen** Konstruktor-/add-Zustand gibt, in dem `totalMinutes()` negativ wird; aktuell prüfst du nur einzelne Parameter, nicht den resultierenden Gesamtzustand (das wird vor allem relevant, sobald du die “nicht verkürzen”-Regel korrekt über `totalMinutes` ausdrückst).\n\n### Suggestion\n- Für die “nur verlängern”-Regel: Merke dir zu Beginn von `add(...)` den aktuellen Gesamtwert (z.B. über `totalMinutes()`), berechne/prüfe dann, ob die beabsichtigte Änderung diesen Wert verringern würde, und wirf in diesem Fall eine `IllegalArgumentException`. Denk daran: Es geht um die Veränderung in **Gesamtminuten**, nicht um das Vorzeichen einzelner Parameter.\n- Wenn du die Precondition über Gesamtminuten formulierst, wird automatisch auch klar, wie du die Nicht-Negativitätsregel robust ausdrückst: orientiere dich an dem öffentlich beobachtbaren Wert `totalMinutes()` (vorher/nachher) statt nur an `hours < 0 || minutes < 0`.\n\n### Code Style\n- `requireNonNegative(hours, minutes)` ist als Hilfsmethode gut; sobald du zusätzlich die “nicht verkürzen”-Prüfung einbaust, wäre es konsequent, die Validierungen klar zu trennen (z.B. eine Methode für Parameter-Checks und eine für Zustands-/Delta-Checks), damit die Intention pro Regel sichtbar bleibt.\n\n\n# Exercise: asteroids\n\n### Correctness\n- In `AsteroidsGame` fehlt ein echtes Java-Entry-Point: Es gibt keine `public static void main(String[] args)`-Methode; mit `void main()` startet das Programm in der Regel nicht wie erwartet.\n- Die Spielfeldbegrenzung des Falcons berücksichtigt die Bild-/Schiffsgrösse nicht: Du clampst `x`/`y` auf `[0..WIDTH]` bzw. `[0..HEIGHT]`, dadurch kann der Falcon (als Bild, das zentriert gezeichnet wird) zur Hälfte aus dem Spielfeld herausragen, obwohl seine Position „im Feld“ ist.\n- Die Asteroid-Grösse entspricht nicht der Aufgabenstellung: gefordert ist `double` zwischen `0.1` und `1.0`, du erzeugst aber nur `0.1` bis `0.3`.\n\n### Suggestion\n- Schau dir an, wie Java-Programme typischerweise gestartet werden: Welche Signatur muss die `main`-Methode genau haben, damit sie als Einstiegspunkt gilt?\n- Überlege beim „im Spielfeld bleiben“: Deine `x,y` sind das Zentrum (weil `drawImageCentered`). Welche Grenzen müsste das Zentrum haben, damit das ganze Sprite sichtbar bleibt? Nutze dafür die (Radius-/Skalierungs-)Grösse des Falcons.\n- Prüfe die Zufallsinitialisierung der Asteroid-`size`: Welche Parameter für `nextDouble(min, max)` brauchst du, damit wirklich der ganze erlaubte Bereich `0.1..1.0` möglich ist?\n\n### Code Style\n- In `Asteroid.java` ist `import java.util.Random;` unbenutzt – entfernen.\n- Mach die Felder, die sich nach dem Konstruktor nicht mehr ändern sollen, konsequent `final` (z.B. `type`, `size`), das macht die Intention klarer.\n- Statt „magic numbers“ wie `0.05`, `1..3`, `20` könntest du benannte Konstanten verwenden, damit man Spawnrate/Speed/Max-Anzahl zentral anpassen kann.\n\n\n# Exercise: bosses\n\n### Correctness\n- \n\n### Suggestion\n- \n\n### Code Style\n- Für `findCommonSuperiorWith` brauchst du zusätzliche Imports (`HashSet`, `Set`). Das ist hier zwar okay, aber in solchen Übungen wird oft eine Lösung “nur mit Referenzen/Schleifen” erwartet; prüfe kurz, ob in den Vorgaben/Tests zusätzliche Datenstrukturen erlaubt sind oder ob explizit eine reine sequentielle Suche ohne Collections gefordert ist.\n- Wenn du schon `getBoss()` hast, könntest du (optional) konsistent über Getter laufen statt direkt `current.boss` zu dereferenzieren; das kapselt das Feld besser und macht spätere Änderungen einfacher.\n\n\n# Exercise: smarthome\n\n### Correctness\n- In `turnNextRoomBright()` verwendest du ein *early return* (`return;`), obwohl die Aufgabenstellung explizit verlangt, möglichst ohne early return (und ohne `break`/`continue`) zu lösen.\n- In `randomize()` erzeugst du die Helligkeit mit `0.5 + random.nextDouble() * 0.5`, das ergibt Werte im Bereich **[0.5, 1.0)**; die Aufgabenbeschreibung sagt „zwischen 0.5 und 1.0“, was typischerweise **inkl. 1.0** verstanden wird.\n\n### Suggestion\n- Für `turnNextRoomBright()`: Überlege dir eine Variante, bei der du das „Zielzimmer“ erst bestimmst (z.B. via Variable/Index/Flag), und **nach** der Suche die Lampen setzt – so kannst du ohne frühzeitiges Verlassen der Methode auskommen.\n- Für `randomize()`: Wenn du sicherstellen willst, dass 1.0 auch möglich ist, prüfe, wie du den Zufallsbereich so konstruieren kannst, dass der obere Rand nicht grundsätzlich ausgeschlossen ist (oder wie man damit in dieser Aufgabe umgehen soll).\n\n### Code Style\n- In `isFullyBright()` vergleichst du `lamp.getBrightness() != 1.0` direkt mit `double`. Das kann wegen Gleitkomma-Darstellung heikel sein; robuster ist ein Vergleich mit Toleranz (z.B. „nahe genug an 1.0“).\n- `Random random = new Random();` in `randomize()` wird bei jedem Aufruf neu erzeugt; häufig hält man dafür ein `Random` als Feld in der Klasse (oder nutzt eine zentrale Zufallsquelle), damit der Code konsistenter/leichter testbar wird.\n",
"status" : "SUCCESS"
}
}