{
"llm" : {
"feedback" : "# Exercise: floodfill\n\n### Correctness\n- In `DrawingApp` ist `RecursiveFloodFill` zwar vorhanden, aber beim Umschalten per ↑/↓ nie auswählbar (in `algorithms` ist nur `IterativeFloodFill[]` enthalten und `recursiveFloodFill` wird nirgends verwendet).\n- Das Umschalten der Algorithmen per ↑/↓ ist inkonsistent: Wenn du von `colorReplace` (Spezialfall) zurückschaltest, wird zwar `fillAlgorithm` auf den letzten Eintrag gesetzt, aber `count` wird dabei nicht passend aktualisiert. Danach kann `count` und der tatsächlich aktive Algorithmus auseinanderlaufen.\n- Bei ↑ (hoch) setzt du am Ende (`count == algorithms.length - 1`) zwar auf `colorReplace`, aber `count` bleibt auf dem letzten Index stehen. Dadurch ist das zyklische Verhalten nicht sauber definiert (du bist “auf ColorReplace”, aber der Index zeigt noch auf den letzten Iterativ-Algorithmus).\n- `IterativeFloodFill.toString()` gibt nur die WorkList zurück; gefordert war, den aktuell ausgewählten Algorithmus in der Statuszeile anzuzeigen (mit `toString`). Das ist zwar grundsätzlich ok, aber so ist z. B. nicht unterscheidbar, ob es ein Flood-Fill-Algorithmus ist oder etwas anderes (bei `ColorReplace` vs. FloodFill ist es bei dir nur indirekt/uneinheitlich sichtbar).\n\n### Suggestion\n- Wenn `RecursiveFloodFill` auswählbar sein soll, überlege dir eine gemeinsame Sammlung (z. B. `List<FillAlgorithm>`) für *alle* Algorithmen, statt ein `IterativeFloodFill[]` plus Spezialfälle.\n- Versuch beim Umschalten immer genau *eine* Quelle der Wahrheit zu haben (nur `algorithmIndex` oder nur `fillAlgorithm`) und sie bei jedem Tastendruck konsistent zu aktualisieren; speziell beim Übergang von/zu `ColorReplace`.\n- Damit die Statuszeile wirklich den “Algorithmus” zeigt, könntest du `IterativeFloodFill.toString()` so gestalten, dass klar ist, dass es Flood Fill ist *und* welche WorkList-Variante verwendet wird (ohne die Logik zu ändern).\n\n### Code Style\n- In `Coord` sind `x` und `y` package-private und werden von aussen direkt gelesen (`coord.x`/`coord.y`); üblich wären `private final` Felder + Getter (macht Objekte stabiler und leichter wartbar).\n- In mehreren Klassen fehlen `@Override`-Annotationen bei Methoden, die Interfaces implementieren bzw. `toString()` überschreiben; das hilft, Tippfehler früh zu erkennen.\n- `DrawingApp`: Viele Felder sind unnötig `public` (`algorithms`, `fillAlgorithm`), obwohl sie nur intern verwendet werden; lieber so restriktiv wie möglich halten.\n- `DrawingApp`: `recursiveFloodFill` ist aktuell ungenutzt (entweder einbauen oder entfernen, damit der Code nicht verwirrt).\n- `IterativeFloodFill`: `workList` sollte ebenfalls `private final` sein (wird nach Konstruktion nicht mehr geändert).\n\n\n# Exercise: flashcard\n\n### Correctness\n- `main()` ist noch leer; damit erfüllt die App aktuell keine der geforderten Funktionen (Laden der Karten, Session-Ablauf, Abfragen, Verschieben zwischen Fächern).\n- In `loadCards(InputStream in)` werden die Karten zwar ausgelesen, aber nicht in ein Lernkartei-System eingefügt (TODO bleibt offen); zudem wird `added` trotzdem für jede Zeile erhöht, auch wenn faktisch nichts hinzugefügt wurde.\n- Es gibt noch keine Implementierung der geforderten Lernkartei-Logik (mehrere Fächer, Karten starten in Fach 1, richtig -> höheres Fach, falsch -> zurück nach Fach 1, Session zieht z. B. 8/4/2 Karten je Fach).\n- Es gibt noch keinen Mechanismus, der Duplikate verhindert (Liste von Sets / LinkedHashSet) und keine Definition von “Duplikat = gleiche Vorderseite” (z. B. via `equals`/`hashCode` einer `FlashCard`-Klasse).\n\n### Suggestion\n- Überleg dir zuerst, welche Klasse die “Logik” kapselt (z. B. `FlashCardSystem`) und welche nur die Ein-/Ausgabe macht (`FlashCardApp`). Dann kann `main()` grob nur: System erstellen → Karten laden → Session starten → wiederholen/enden.\n- Beim Laden aus TSV: statt `added++` pro Zeile könntest du `added` nur erhöhen, wenn das System die Karte tatsächlich akzeptiert hat (z. B. wenn sie kein Duplikat ist).\n- Für Duplikate: baue eine `FlashCard`-Klasse, bei der die “Identität” nur von der Vorderseite abhängt. Denk daran, dass Sets dafür konsistente `equals`/`hashCode` brauchen.\n- Für die Fächer: starte mit einer `List<LinkedHashSet<FlashCard>>` und einer Methode wie “addCard” (immer in Fach 1, aber nur falls noch nicht irgendwo enthalten) sowie “markCorrect/markWrong”, die die Karte zwischen Sets verschiebt.\n- Für den Session-Mechanismus: definiere eine klare Regel, wie viele Karten aus jedem Fach drankommen (z. B. abhängig von der Fachnummer) und wie du auswählst, welche Karten aus einem Fach “die nächsten” sind (LinkedHashSet hilft dir bei stabiler Reihenfolge).\n\n### Code Style\n- In `loadCards(InputStream in)` wäre es robuster/lesbarer, vor dem Zugriff auf `parts[1]` sicherzustellen, dass die Zeile wirklich zwei Spalten hat (sonst fliegt bei fehlerhaften Zeilen schnell ein `ArrayIndexOutOfBoundsException`).\n- Die Variable `lines` lädt alles auf einmal in eine Liste; bei grösseren Dateien wäre es oft cleaner, direkt über den Stream zu iterieren (ist kein Muss, aber häufig angenehmer).\n\n\n# Exercise: imagestats\n\n### Correctness\n- Du hast das Problem bereits behoben, indem du `hashCode()` ergänzt hast; die Übung verlangt aber ausdrücklich, das Problem nur zu untersuchen/einzugrenzen und mit einem Minimalbeispiel zu reproduzieren, nicht es zu lösen.\n\n### Suggestion\n- Stelle den Zustand wieder her, in dem das fehlerhafte Verhalten auftritt, und versuche dann mit einem sehr kleinen Programm (z.B. nur `HashMap`/`HashSet` + zwei identische `Color`-Objekte) zu zeigen, dass Duplikate nicht erkannt werden.\n- Dokumentiere in deinem Minimalbeispiel klar die Erwartung vs. tatsächliche Ausgabe (z.B. erwartete Größe 1, tatsächlich 2), damit das Problem unabhängig vom Bildprogramm sichtbar ist.\n\n### Code Style\n- Füge bei `equals` und `hashCode` die Annotationen `@Override` hinzu, damit der Compiler dich warnt, falls die Signatur nicht exakt passt.\n",
"status" : "SUCCESS"
}
}