Each The Scala assignment
play call should make at most one hit and return true exactly when it did so; the supplied while loop invokes it again to decide whether another hit is needed. Add these accessors inside Player:def cards: List[Int] = _cards
def cards_=(cs: List[Int]): Unit = { _cards = cs }
def visibleValue: Int = _visibleValue
def visibleValue_=(v: Int): Unit = { _visibleValue = v }temp.cards = cs calls the setter, and visibleValue += cards.head uses the getter followed by the setter. The list getter exposes an immutable list value; updating the player's field still goes through the setter. The supplied initialization and hit maintain the hidden card at the last list position and visibleValue == cards.init.sum for each nonempty dealt hand.The concrete software classes implement the supplied strategies literally:
class Regular extends Player {
def play(visibleCards: List[Int]): Boolean = {
require(visibleCards.length == 1)
val total = value
if (total < 21 && total <= 21 - visibleCards.head) {
hit
true
} else false
}
}
class Optimistic extends Player {
def play(visibleCards: List[Int]): Boolean = {
if (value != 21) {
hit
true
} else false
}
}
class House extends Player {
def play(visibleCards: List[Int]): Boolean = {
val total = value
if (total < 21 && visibleCards.forall(v => total <= 21 - v)) {
hit
true
} else false
}
}House receives all other players' final visible totals, whereas a non-house player receives the singleton containing the house's first visible card. The universal test implements “for each other player,” including the vacuously true case of no other players. Subtype polymorphism gives the common player list a Player interface, and dynamic dispatch chooses the appropriate play implementation.These are the literal missing methods, but the printed specification does not guarantee a terminating game. An optimistic player with total who draws reaches ; every further positive card keeps the total above , so
value != 21 remains true. The claim that only finitely many further cards are requested is therefore inconsistent with the optimistic strategy on such executions, in the intended arithmetic model without overflow. If the intended rule is “stop on reaching or exceeding 21,” the necessary correction is to replace its test by value < 21; that changes the printed strategy and is not silently made here.There is a second printed mismatch:
nextInt(10) yields , so 1 + nextInt(10) yields , not . Preserve the supplied hit when filling its missing pieces; generating every value from through would require an explicit change to nextInt(11) in both dealing and hitting.[ref]https://www.scala-lang.org/api/2.11.12/scala/util/Random.html#nextInt(n:Int):Int. Scala 2.11.12 Random.nextInt, upper bound is exclusive
No winner-computation code is requested; the supplied loop only deals and requests cards. Articles by others on the same topic
There are currently no matching articles.