{
"llm" : {
"feedback" : "# Exercise: textanalysis\n\n### Correctness\n- `topWordK(int k)` erfüllt die optionale Zusatzaufgabe nicht korrekt: Gefordert ist das *k*-häufigste Wort (ein einzelnes `String`) **oder** ein `String`-Array mit den *k* häufigsten Wörtern – du gibst aber die `toString()`-Darstellung einer `ArrayList` zurück (inkl. `[` `]` und Kommas), was nicht dem geforderten Rückgabetyp/Format entspricht.\n- `topWordK(int k)` ist nicht `public`, kann also (je nach Tests/Benutzung) von außen evtl. nicht aufgerufen werden, obwohl die Zusatzfunktion als Teil der Klasse vorgesehen ist.\n- In `TextAnalyzer` gibst du `Most frequent words: \"` aus, rufst aber `topWordK(3)` auf, das bei dir kein klares “Wörter”-Ergebnis im geforderten Format liefert (siehe oben); damit ist die Ausgabe inhaltlich/formatbedingt nicht passend zur Aufgabenidee.\n\n### Suggestion\n- Entscheide dich für **eine** der beiden Spezifikationen der Zusatzaufgabe: entweder wirklich “das k-häufigste Wort” als einzelner `String`, oder ein echtes `String[]` mit den Top-*k*-Wörtern; richte Signatur und Rückgabe dann strikt danach aus (nicht über `List.toString()`).\n- Falls du die Top-*k*-Wörter liefern willst: überlege, wie du aus deiner `ArrayList<String>` am Ende ein `String[]` machst, statt einen formatierten List-String zurückzugeben.\n- Prüfe, ob die Methode von außerhalb der Klasse aufrufbar sein soll; wenn ja, gleiche die Sichtbarkeit an die anderen Methoden an.\n- Denk auch daran, was passieren soll, wenn `k` größer ist als die Anzahl unterschiedlicher Wörter: im Moment fügst du dann ggf. leere Strings hinzu (weil kein Kandidat gefunden wird).\n\n### Code Style\n- `import java.util.Arrays;` ist unbenutzt und kann entfernt werden.\n- `words` sollte typischerweise `private` sein (Kapselung), analog zur Idee “interne Datenstruktur”.\n- In `topWordK` rufst du zuerst `topWord()` auf und iterierst danach für jeden weiteren Platz erneut über alle Entries; das ist zwar ok für kleine Datenmengen, aber bei großen Texten ineffizient. Eine klarere/effizientere Strategie wäre z.B. einmaliges Sortieren/Ranking (ohne dass du gleich die komplette Lösung umschreibst).\n\n\n# Exercise: lotto\n\n### Correctness\n- `Lottery.buyTicket`: Du prüfst `numbers.length < 6`, aber nicht den Fall `numbers.length > 6`; gefordert sind **genau** 6 Zahlen.\n- `Lottery.draw` ist noch nicht implementiert; dadurch werden keine 6 zufälligen, verschiedenen Gewinnzahlen gezogen/gespeichert.\n- Zustandsregeln: Nach der Ziehung darf `draw()` nicht nochmals aufgerufen werden; diese `IllegalStateException`-Prüfung fehlt aktuell (weil `draw` komplett TODO ist).\n- `Ticket`: Du speicherst die Ticket-Zahlen nirgends (Instanzvariable fehlt) und die Methoden `getNumbers`, `getCorrectNumbers`, `getPrize` sind nicht implementiert; damit kann das Ticket weder Zahlen zurückgeben noch korrekte Zahlen/Preis berechnen.\n\n### Suggestion\n- Für die “genau 6 Zahlen”-Bedingung: Überlege dir, welche Längen überhaupt erlaubt sind, und prüfe diese Bedingung **einmal** zentral statt in der Schleife über die Zahlen.\n- Für `draw()`: Du brauchst eine Collection, die automatisch Duplikate verhindert, und füllst sie, bis sie Größe 6 hat; zusätzlich vorher prüfen, ob schon gezogen wurde.\n- Für `Ticket`: Lege eine passende Datenstruktur als Instanzvariable an, in die du die 6 Zahlen im Konstruktor kopierst (nicht nur die Referenz behalten), und gib in `getNumbers()` eine Kopie davon zurück.\n- Für `getCorrectNumbers()`: Du kannst die Gewinnzahlen über die Lottery abfragen und dann die Schnittmenge zwischen Ticketzahlen und Gewinnzahlen bestimmen; denk daran, dass diese Methode vor der Ziehung eine `IllegalStateException` auslösen soll (entweder direkt oder indirekt).\n- Für `getPrize()`: Verwende die Anzahl korrekter Zahlen als Basis und bilde daraus den Preis gemäß “0→0, 1→5, jede weitere *20”; teste gedanklich die Werte für 2, 3, …, 6 Richtige.\n\n### Code Style\n- In `Lottery.java` ist `import java.util.Arrays;` unbenutzt.\n- In `buyTicket` ist die Duplikatprüfung mit einer verschachtelten Schleife unnötig aufwändig und schwer lesbar; eine Collection-basierte Prüfung (passend zur Aufgabenstellung “Collections verwenden”) macht das klarer.\n- Die Längenprüfung (`numbers.length < 6`) innerhalb der Schleife über die Zahlen ist redundant und erschwert das Verständnis; solche Vorbedingungen sind besser als separater Guard-Check am Anfang der Methode.\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.IllegalStateException to be thrown, but nothing was thrown."
}, {
"name" : "getWinningNumbersNotDrawnYet()",
"status" : "FAILED",
"message" : "Unexpected exception type thrown, expected: <java.lang.IllegalStateException> but was: <java.lang.reflect.UndeclaredThrowableException>"
}, {
"name" : "buyTicketAlreadyDrawn()",
"status" : "FAILED",
"message" : null
} ]
}
}