Muffi

PS: ich hab NUR start angeschaut. Wenn man den Ablauf versteht ohne in die jeweiligen Funktionen zu gehn glaub ich ist der Code top.

Oh, danke, das ist nett! Man bekommt ja nicht oft Lob, meist hört man gar nichts, wenn alles in Ordnung ist oder es kommt Kritik, wahrscheinlich, weil der Interpreter das auch so macht. :)

Muffi

Die show-präfixe haben mir zu viel Zweck im Namen. Für was ich die Funktion aufrufe braucht sie nicht zu kümmern.
Z. 25: sieht nach hack aus. Ich würd ein is_bot erwarten oder ähnliches.
Z. 26: sieht auch komisch aus. Warum nicht gleich eine Player-methode, die einen gültigen Zug fertig zurückgibt. Oder evtl. ein do-while?
Wenn man nun weiterspinnen würde hätten Mensch und bot gleiches Verhalten. Also würden wohl beide von Player erben und hätten ein getAnswer.
Z. 33: getsticks klingt nach Anzahl zurückliefern. Also nach nem normalen getter. Auch ist mal von size und mal von sticks die Rede, vielleicht kann man das durchgängiger benamen.

Das ist sicher alles richtig. Daß ich die Namen nicht immer nach üblichen Standards vergebe, liegt daran, daß ich diese (noch) nicht kenne; ich hab' das ja nicht in Schule oder Studium gelernt, sondern mir selbst angelesen. Beim nächsten "Projekt" werde ich versuchen, mehr drauf zu achten. Dieses läuft ja erstmal so, wenn's wichtig wär', würd' ich es bestimmt noch weiter entwickeln.
Dann würde ich sicher auch versuchen zu berechnen, wie es wäre, wenn eine andere Zahl als 17 Hölzer am Anfang zur Verfügung stehen und Spieler eine andere Zahl als 3 Hölzer pro Zug wegnehmen dürfen. So wie es jetzt ist, gibt es noch "Magic Numbers", die man vermeiden sollte.

Muffi

Z. 36: ist mir nicht klar was das tut.

Das setzt die Größe des Holzstapels herab, weil ja was weggenommen wurde. Ist aber nicht gut: Die "->getSticks()"-Methode hätte das gleich miterledigen sollen.

Muffi

Z. 37: ein recht versteckter last.

Ja, diese Zeile war in dem Fall nötig, wenn z.B. nur noch 2 Hölzer da sind, der Spieler aber 3 wegnimmt. Soll eigentlich auch nicht sein, vielleicht hätte man das auch an anderer Stelle prüfen sollen.

Jedenfalls vielen Dank, daß Du mal drübergeguckt hast.

Wie gesagt, hab' ich OOP nicht auf dem ordentlichen Weg gelernt. Ich habe daher meist Probleme, die Objekte so miteinander kommunizieren zu lassen, wie es eigentlich sein soll. Vor allem fällt mir schwer, den Programmablauf einerseits und die Kommunikation der Objekte andererseits richtig zu verbinden.
Es kommt vor, daß ein (verpöntes) "God object" entsteht.
Oft "mißbrauche" ich Klassen auch als bloße Container für Variablen und Funktionen. (Das mache ich oft, ich finde es auch lustig, daß Perl5 (im Gegensatz zu anderen Sprachen) bei Klassen von "Packages" spricht, das entspricht dieser Idee in etwa.)
Eine Idee für ein wirkliches "Objekt", also für etwas, daß Gegenstände der realen Welt in der Programmierung nachbildet, habe ich nur sehr selten. Hier sind es eigentlich nur die Klassen "Stick" und "Player", die so arbeiten. Der Rest sind Hilfskonstrukte, damit das Programm irgendwie läuft.
Das war auch der Grund, warum ich dieses Beispiel jetzt überhaupt geschrieben hatte: Ich dachte, wenn man "Stick"-Objekte hätte, könnte man die wirklich "Player"-Objekten zuführen anstatt nur bloße Zahlen etwa in einem Array zu verarbeiten. Das ist ja auch gelungen, aber sauberes OOP-Design ist es wohl noch nicht, soweit bin ich immer noch nicht. Also, wahrscheinlich ist dieser Code noch nicht ganz "top", aber ich freue mich natürlich trotzdem über Dein Lob.