{
"llm" : {
"feedback" : "# Exercise: textanalysis\n\n### Correctness\n- In `add`, beim ersten Auftreten eines Wortes speicherst du den Zähler als `0`; dadurch sind alle Häufigkeiten um 1 zu klein und das „am häufigsten vorkommende Wort“ kann dadurch verfälscht werden (z.B. bei Texten mit nur einmal vorkommenden Wörtern).\n- `topWord` startet mit `startvalue = 0` und aktualisiert nur bei `>`; wenn alle Wörter (wegen des obigen Off-by-one oder auch generell) den Wert `0` haben, bleibt `TopWord` leerer String statt ein vorhandenes Wort zurückzugeben.\n\n### Suggestion\n- Überlege dir, welche Zahl in der Map stehen sollte, wenn du ein Wort zum ersten Mal siehst: Nach dem ersten `add` sollte die Häufigkeit dieses Wortes bereits „1“ anzeigen.\n- Denke darüber nach, wie `topWord` entscheiden soll, wenn mehrere Kandidaten die gleiche Häufigkeit haben oder wenn der höchste Zähler genau deinem Startwert entspricht: entweder Startwert passend wählen oder die Vergleichslogik so anpassen, dass auch der erste Eintrag eine Chance hat.\n\n### Code Style\n- Benenne Variablen konsistent nach Java-Konventionen: z.B. `topWord`/`topWordCandidate` statt `TopWord`, und `startValue` statt `startvalue`.\n- Mach das Feld `wordList` besser `private`, damit die interne Datenstruktur von außen nicht verändert werden kann.\n\n\n# Exercise: lotto\n\n### Correctness\n- `Lottery.buyTicket` gibt bei ungültigen Eingaben `null` zurück statt wie gefordert eine `IllegalArgumentException` zu werfen.\n- `Lottery.buyTicket` prüft nicht, ob nach der Ziehung noch Tickets gekauft werden (es fehlt die `IllegalStateException`, wenn bereits gezogen wurde).\n- `Lottery.buyTicket` prüft nicht, ob alle 6 Zahlen **verschieden** sind.\n- `Lottery.buyTicket` prüft die Grenzen nicht korrekt: die Bedingung verwendet `< maxNumber` statt `<= maxNumber` (die Höchstzahl muss erlaubt sein).\n- `Lottery.buyTicket` erhöht `soldTickets` nicht; damit stimmen IDs und `getSoldTickets()` nicht (ID muss 1,2,3,… sein).\n- Die Schleifenlogik in `buyTicket` ist fehlerhaft (du greifst auf `numbers[nextNumberCounter]` zu, bevor du sicherstellst, dass der Index noch gültig ist; außerdem ist die Abbruch-/Zählbedingung so, dass du nicht zuverlässig alle 6 Werte korrekt validierst).\n- `Lottery.draw` ist nicht implementiert (muss 6 zufällige, verschiedene Gewinnzahlen ziehen, Zustand prüfen, speichern).\n- In `Ticket` sind Konstruktor (Zahlen speichern) sowie `getNumbers`, `getCorrectNumbers`, `getPrize` nicht implementiert, damit kann die App/Tests den Gewinn nicht berechnen und die Zustandsregeln werden nicht eingehalten (z. B. `IllegalStateException` vor der Ziehung).\n\n### Suggestion\n- Statt `null` zurückzugeben: überlege dir, **an welchen Stellen** du laut Aufgabenstellung eine Exception werfen musst (ungültige Zahlen vs. falscher Zustand) und ersetze die „silent failure“-Rückgabe entsprechend.\n- Baue die Validierung in `buyTicket` so auf, dass du **alle 3 Anforderungen** abdeckst: (1) genau 6 Zahlen, (2) jede Zahl im Bereich `1..maxNumber` (inklusive max), (3) keine Duplikate (eine `Set`-Struktur eignet sich gut zum Erkennen).\n- Für die Ticket-ID: denke daran, dass `soldTickets` der Zähler ist, der beim Kauf **hochgezählt** wird; die neue ID kann dann direkt daraus abgeleitet werden.\n- Für `draw`: du brauchst eine Datenstruktur, die automatisch „verschiedene“ Elemente erzwingt, und eine Schleife, die so lange zieht, bis genau 6 drin sind; zusätzlich musst du verhindern, dass `draw()` zweimal aufgerufen wird.\n- In `Ticket`: speichere die 6 Zahlen in einer eigenen Instanzvariable, gib in `getNumbers()` eine Kopie zurück, und für `getCorrectNumbers()` nimm die Gewinnzahlen der `lottery` und ermittle die Schnittmenge mit den Ticket-Zahlen (aber achte darauf, nichts „internes“ ungewollt zu verändern).\n- Bei `getPrize()`: leite den Gewinn ausschließlich aus der Anzahl korrekter Zahlen ab (0 → 0; 1 → BASE_PRIZE; jede weitere Zahl multipliziert mit MULTIPLIER) und stelle sicher, dass vor der Ziehung die passende `IllegalStateException` entsteht.\n\n### Code Style\n- Vermeide magische Zahlen wie `5`/`6` im Codefluss (`<=5`, `==5`); wenn „6 Zahlen“ eine feste Regel ist, verwende eine Konstante oder arbeite direkt mit `numbers.length`.\n- Die Validierungslogik in `buyTicket` ist schwer nachvollziehbar durch `nextNumberCounter`, mehrfaches Setzen von `number` und die `while`-Bedingung; strukturierter (z. B. klarer Loop über alle Elemente + separate Checks) wird leichter testbar und weniger fehleranfällig.\n- `buyTicket` hat noch `// TODO`, aber bereits Logik: entweder TODO entfernen, oder die Methode sauber fertigstellen, damit der Kommentar nicht irreführend bleibt.\n",
"status" : "SUCCESS"
},
"unitTest" : {
"tests" : [ {
"name" : "buyTicketIds()",
"status" : "FAILED",
"message" : null
}, {
"name" : "buyTicketsIllegalNumbers()",
"status" : "PASSED",
"message" : null
}, {
"name" : "draw()",
"status" : "FAILED",
"message" : "expected: <true> but was: <false>"
}, {
"name" : "drawNoDuplicates()",
"status" : "FAILED",
"message" : null
}, {
"name" : "drawRandom()",
"status" : "FAILED",
"message" : null
}, {
"name" : "drawAlreadyDrawn()",
"status" : "FAILED",
"message" : "Expected java.lang.Exception to be thrown, but nothing was thrown."
}, {
"name" : "getWinningNumbersNotDrawnYet()",
"status" : "FAILED",
"message" : null
}, {
"name" : "buyTicketAlreadyDrawn()",
"status" : "FAILED",
"message" : null
} ]
}
}