{
"llm" : {
"feedback" : "# Exercise: floodfill\n\n### Correctness\n- `WorkList` deklariert `add` als `default` mit leerem Body; damit ist `add` nicht abstrakt wie in der Aufgabe gefordert und eine fehlerhafte `WorkList`-Implementierung könnte “funktionieren”, ohne je Elemente zu speichern.\n- `WorkHashSet.remove()` entfernt kein Element korrekt und gibt immer `null` zurück; dadurch wird `IterativeFloodFill` mit `WorkHashSet` beim ersten `remove()` mit hoher Wahrscheinlichkeit in eine `NullPointerException` laufen (`c.x`, `c.y`).\n- In `RecursiveFloodFill` vergleichst du Farben einmal mit `!=` (`img.getPixel(x, y) != oldColor`) statt mit `.equals(...)`; das kann dazu führen, dass Pixel mit “gleichem Farbwert” nicht als gleich erkannt werden und dann nicht geflutet werden.\n- Die Umschaltung der Algorithmen mit ↑/↓ ist nicht entsprechend der Tasten implementiert: aktuell wird bei “up **oder** down” immer `modeIndex = (modeIndex + 1) % 3` ausgeführt, d. h. beide Tasten schalten in die gleiche Richtung.\n- Wenn du per Taste `1/2/3` eine neue `IterativeFloodFill(...)` erzeugst, bleibt `mode` ggf. auf der alten `iterativeFloodFill`-Instanz stehen (falls Iterativ gerade aktiv ist, erwartest du aber normalerweise, dass sich das Verhalten sofort ändert).\n\n### Suggestion\n- Schau dir das Interface-Design nochmal an: Wenn jede WorkList eine eigene Datenstruktur kapseln soll, sollte `add` nicht “optional” sein. Überlege, wie du im Interface erzwingst, dass jede Implementierung eine echte `add`-Methode bereitstellt.\n- Für `WorkHashSet.remove()`: du brauchst erst *ein konkretes Element* aus dem Set (z. B. via Iterator), und dann musst du genau dieses entfernen und zurückgeben. Prüfe, was `iterator().remove()` ohne vorheriges `next()` überhaupt bedeutet.\n- Beim Flood-Fill hängt alles daran, Farben korrekt zu vergleichen. Achte darauf, konsequent `.equals(...)` zu verwenden (und nicht Referenzvergleich), weil `getPixel` dir ggf. unterschiedliche `Color`-Objekte mit gleichen Werten liefern könnte.\n- Für ↑/↓: trenne die beiden Fälle wie bei links/rechts (bei ↑ Index runter, bei ↓ Index rauf) und normalisiere danach mit Modulo.\n- Wenn du zur Laufzeit das WorkList-Verhalten wechseln willst, überlege, wie `mode` an die neu erzeugte `iterativeFloodFill`-Instanz gekoppelt bleibt (oder wie du stattdessen nur intern die WorkList tauschst, ohne das Algorithmus-Objekt auszutauschen).\n\n3. Code Style:\n- Du hast eine eigene `Color`-Klasse im gleichen Package, verwendest aber überall `ch.trick17.gui.Color`; die eigene Klasse wirkt hier unbenutzt/verwirrend.\n- Viele `System.out.println(...)` Debug-Ausgaben (z. B. in `setPixel`, `WorkStack`, `WorkQueue`, FloodFill) stören die Ausgabe und sollten entfernt werden, wenn es funktioniert.\n- `Coord` hat öffentliche package-sichtbare Felder (`int x; int y;`) und keinen klaren `Comparable`-Vertrag (compareTo immer 0); entweder sauber kapseln (Getter/immutable) oder den ungenutzten `compareTo` weglassen.\n- `Coord.hashCode()` über String-Konkatenation/parseInt ist unnötig kompliziert und kann kollidieren; außerdem ist es potenziell fehleranfällig bei größeren Koordinaten.\n- In `DrawingApp` gibt es tote/ungenutzte Teile (`createList()`, `workIndex`, auskommentierte Listen) und teils inkonsistente Feldformatierung (`FillAlgorithm mode=colorReplace;` ohne Leerzeichen/Indent).\n\n\n# Exercise: flashcard\n\n### Correctness\n- Die Logik des Lernkartei-Systems mit mehreren Fächern ist nicht umgesetzt: Du speicherst alle Karten in genau *einem* `Set`, statt wie gefordert in einer *Liste von Sets* (pro Fach ein Set).\n- Das “Session”-Verhalten (z. B. bei 3 Fächern: 8 Karten aus Fach 1, 4 aus Fach 2, 2 aus Fach 3) fehlt komplett.\n- Karten starten nicht “in Fach 1” und werden auch nicht zwischen Fächern verschoben wie gefordert (richtig -> nächsthöheres Fach, falsch -> zurück in Fach 1). Stattdessen veränderst du nur eine globale Variable `compartment`, die nicht an eine konkrete Karte gebunden ist.\n- In `learn()` ist der Ablauf der Benutzereingabe falsch: Du liest nur *einmal* `input` ein (“Enter”), fragst danach zwar “(y/n)”, liest dafür aber keine neue Eingabe mehr ein. Dadurch wird `compartment++/--` praktisch nie korrekt ausgelöst.\n- Duplikaterkennung “gleichwertig wenn gleiche Vorderseite” ist nicht korrekt umgesetzt: `FlashCard.equals` gibt für zwei verschiedene Objekte immer `false` zurück (außer identische Referenz). Damit kann dein `LinkedHashSet` keine Duplikate anhand der Vorderseite verhindern.\n- `hashCode()` nutzt `front` und `back`; laut Aufgabe soll die Gleichwertigkeit nur über die Vorderseite laufen (sonst gelten gleiche Front aber anderes Back nicht als Duplikat).\n- `add <front>/<back>` ist als Kommando zwar vorhanden, aber `addCards()` ist leer und parst auch nicht das übergebene `<front>/<back>` aus der Eingabe.\n- Am Ende von `main()` rufst du `card.loadCards(input);` auf, wobei `input` dort `\"exit\"` ist. Das führt dazu, dass beim Beenden noch versucht wird, eine Resource namens `exit` zu laden (nicht gefordert und funktional falsch).\n\n### Suggestion\n- Überlege dir eine Datenstruktur, die wirklich “Fächer” abbildet: z. B. eine `List<Set<FlashCard>>`, wobei jedes List-Element ein Fach ist. Dann kannst du Karten gezielt zwischen Fächern verschieben.\n- Plane die Lern-Session so, dass du pro Fach eine bestimmte Anzahl Karten auswählst (abhängig von der Fachnummer). Du brauchst dafür eine Regel/Funktion, die aus “Fach i” die “Anzahl Karten für diese Session” bestimmt.\n- Statt einer globalen `compartment`-Zahl: Speichere, *in welchem Fach* eine bestimmte Karte liegt (implizit durch das Set, in dem sie enthalten ist). Beim Beantworten entfernst du die Karte aus dem alten Fach-Set und fügst sie dem neuen hinzu.\n- Passe `equals`/`hashCode` so an, dass zwei Karten als gleich gelten, wenn die Vorderseite gleich ist. Wichtig: `equals` und `hashCode` müssen konsistent sein, sonst funktionieren Sets nicht zuverlässig.\n- In `learn()`: Lies die Eingaben in zwei Schritten (1× Enter zum Anzeigen, danach nochmal y/n einlesen). Achte darauf, dass du die y/n-Eingabe wirklich neu einliest, bevor du entscheidest.\n- Für `add <front>/<back>`: Nutze den eingegebenen String aus `main()` (nicht eine leere Methode ohne Parameter). Zerlege ihn an der Trennstelle `/` und erzeuge daraus eine neue Karte.\n\n3. Code Style:\n- `Scanner scanner = new Scanner(System.in);` wird in `learn()` in jeder Schleifeniteration neu erstellt. Besser: einmalig erstellen und wiederverwenden (z. B. in `FlashCardApp` oder als Feld).\n- In `learn()` nutzt du einmal `flashCard.getFront()`, aber beim Back greifst du direkt auf `flashCard.back` zu. Einheitlicher Zugriff (z. B. Getter) macht die Klasse konsistenter.\n- `CardMethods` ist als Name unklar: Die Klasse macht mehr als “Methoden”, sie ist eher dein System/Model. Ein domänenspezifischer Name (z. B. `FlashCardSystem`) wäre verständlicher.\n- Auskommentierter alter Code in `FlashCardApp` macht das schwer lesbar; entferne ihn, sobald du die neue Struktur hast.\n- `showAnswer(String flashCard)` ist unbenutzt und leer. Entweder implementieren oder entfernen.\n\n\n# Exercise: imagestats\n\n### Correctness\n- Du hast das Problem „gelöst“, indem du `hashCode()` ergänzt hast. In der Aufgabe sollst du das Problem aber nur untersuchen und mit einem Minimalbeispiel reproduzieren, **nicht beheben**.\n- Deine `hashCode()`-Berechnung ist inhaltlich falsch: Sie ist nicht konsistent zur `equals()`-Definition (d. h. gleiche `r,g,b` müssen garantiert denselben Hash liefern). Dadurch kann das Verhalten von `HashMap`/`HashSet` weiterhin fehlerhaft oder zufällig wirken.\n\n### Suggestion\n- Lass `Color` so, dass das ursprüngliche Problem weiterhin auftritt, und versuche stattdessen ein winziges Programm zu schreiben, das nur mit `HashMap<Color, Integer>` oder `HashSet<Color>` arbeitet und das doppelte Einfügen derselben Farbe zeigt.\n- Wenn du trotzdem (für dein Verständnis) einen `hashCode()` testen willst: Überprüfe mit einem kleinen Test, ob zwei `Color`-Objekte mit identischen `r,g,b` wirklich **denselben** `hashCode()` liefern, und ob dein Ausdruck tatsächlich alle drei Komponenten korrekt „einmischt“ (achte besonders darauf, wo du multiplizierst vs. addierst).\n\n### Code Style\n- `import java.util.Objects;` ist unbenutzt (weil `Objects.hash(...)` auskommentiert ist).\n- `System.out.println(histogram.get(pixel));` in der innersten Schleife erzeugt extrem viel Output und macht das Programm sehr langsam; für Debugging besser gezielt (z. B. nur am Ende oder bei bestimmten Bedingungen) ausgeben.\n- Der auskommentierte alternative `hashCode()`-Return kann raus oder als klare „Experiment“-Variante dokumentiert werden, damit der Code nicht „halb debug / halb final“ wirkt.\n",
"status" : "SUCCESS"
}
}