nicht angemeldet
Also so, wie man es auch prozedural machen würde: Die Procedur oder Funktion vergleicht die Kartenwerte.
Ja. In OO heißt das dann Methode, da die Funktion zu einer Klasse gehört. Ist aber vom Verhalten her das selbe.
Fehlt noch eine Klasse Spieler. Deren Objekte können eine Karte wählen (durch Benutzereingabe oder zufällig), cheaten und kennen ihren Punktestand - richtig?
Ja.
Cheaten?
Hinter der Antwort wie du das genau designen solltest, steckt zunächst mal: willst du was praktisches machen das funktioniert und genügend sauber aber nicht unnötig komplex ist, oder möchtest du sozusagen ein Lehrbeispiel machen in dem alles durch und durch objektorientiert ist, auch wenn es für deine Situation nicht nötig ist und so schnell auch nicht sein wird.
Du kannst schon auch für jeden Kartenwert (also Schere usw) eine eigene Karten-Klasse erstellen, von einer Basisklasse ableiten, dann im Konstruktur jeweils Eigenschaften setzen (Typ = Schere ...), Vergleichsmethoden für den Vergleich der aktuellen Kartenklasse mit einer anderen usw... Damit hättest du einen wunderbaren höchst objektorientierten Code laut Lehrbuch.
Aber du machst dir eine wahnsinns Arbeit. Du hättest Klassen die sich in nur einer einzigen Eigenschaft unterscheiden. Viel Code, kaum Unterschied.
Du könntest in jeder Klasse die Vergleiche der jeweiligen Klasse mit allen anderen einbauen, also Schere weiß ob sie im Vergleich mit allen anderen Karten gewinnt oder verliert, Stein weiß das ebenfalls für sich usw. Aber du reißt dadurch die Logik der Vergleiche auseinander. Die würde ich lieber in einer einzigen Funktion/Methode halten. Die kann in der Basisklasse stecken, oder wenns nur eine einzige Klasse bleibt, eben in dieser.
Matthias Apsel
Auge