In this task you will implement a Player and Dealer class, which are able to make decisions about how to play the game based on the cards they have on hand.

Background

Players are initially given two cards, and the choice to either "stay" $($meaning to not accept any new cards$)$ or "hit" $($meaning to accept an additional card$).$ If they choose to stay, then their hand $($and it's resulting score$)$ is finalised. If they choose to hit, then they will be given another card, which will increase their score and potentially make them go bust. Players can continue "hitting" as many times as they like until they either go bust, or choose to stay.

In blackjack, players don't compete against each other. Instead, each player competes against the dealer. While players are completely free to make their own decisions, dealers have strict rules to follow that determine whether they stay or fold, depending on the cards in their hand.

If the value of the dealer's hand is less than $17,$ they must hit and take an additional card.

If the value of the dealer's hand is $17$ or more, they must stay.

They also have strict rules to follow when deciding how to use any aces in their hand.

If the dealer has an ace, they must count it as $11$ unless it would cause them to go bust. Otherwise they must count it as a $1.$

In other words, the dealer's decisions are entirely predictable and automatic. This makes it a good candidate for us to automate!

Specification

The Agent abstract class or interface $($your choice$)$ must define the following contract:

A getHand method, which accepts no parameters, and returns the agent's current hand as a List of Card.

A getScore method, which accepts no parameters, and returns the score of the agent's current hand as an int.

An isStaying method, which accepts no parameters, and returns true if the agent wants to stay, or false if not.

An isBust method, which accepts no parameters, and returns true if the agent is currently bust, or false if not.

A take method, which accepts a Card as input, and returns nothing. Calling this method should cause the given card to be added to the agent's hand. You can assume this method will only be called when the agent is not staying and not bust.

If you implement Agent as an abstract class, you are free to decide which methods are abstract and which are concrete.

The Player class must implement or extend the Agent interface$/$class$.$ In addition to implementing the contract provided by Agent, it must provide:

A constructor that accepts an instance of Scanner as input, and results in a player that has an empty hand of cards, and is not staying or bust.

The isStaying method must allow the user to decide whether they are staying or not using the following steps:

Print the prompt $"($h$)$it or $($s$)$tay$"$ to the console.

Wait for the user to type in $"$h$"$ or $"$s$"$ in response $($using the scanner provided when the player was first created$).$

If the user types anything other than $"$h$"$ or $"$s$"$ the method should print "Invalid response, try again" and then wait for the user to provide a new response. It should continue to do this for as long as it takes for the user to enter either $"$h$"$ or $"$s$".$

If the user enters $"$h$"($for hit$)$ the method should return false. If they enter $"$s$"($for stay$),$ it should return true.

The Dealer class must implement or extend the Agent interface$/$class$.$ In addition to implementing the contract provided by Agent, it must provide:

A constructor that accepts no parameters, and results in a dealer that has an empty hand of cards, and is not staying or bust.

The isStaying method must follow the rules discussed above in the Background section to decide whether the dealer is staying or not.

Examples

Here are some examples of the output of the runner if you leave it unchanged, and implement the classes correctly:

Starting hand: $[$Q$,10]$ Score:$20$

Staying.

Starting hand: $[2,9]$ Score:$11$

Hitting.

Hand: $[2,9,$ K$]$ Score:$21$

Staying.

Starting hand: $[6,$ K$]$ Score:$16$

Hitting.

Hand: $[6,$ K$,9]$ Score:$25$

Bust!

Here are some examples of the output of the runner if you edit it to use the Player class rather than the Dealer:

Starting hand: $[6,$ Q$]$ Score:$16$

$($h$)$it or $($s$)$tay$?$

h

Hitting.

Hand: $[6,$ Q$,5]$ Score:$21$

$($h$)$it or $($s$)$tay$?$

s

Staying.

Starting hand: $[$J$,4]$ Score:$14$

$($h$)$it or $($s$)$tay$?$

f

Invalid choice, try again

z

Invalid choice, try again

h

Hitting.

Hand: $[$J$,4,$ A$]$ Score:$15$

$($h$)$it or $($s$)$tay$?$

h

Hitting.

Hand: $[$J$,4,$ A$,4]$ Score:$19$

$($h$)$it or $($s$)$tay$?$

h

Hitting.

Hand: $[$J$,4,$ A$,4,$ K$]$ Score:$29$

Bust!

Hints

Expand

The Player and Dealer classes are almost identical, the only difference is the constructor and the implementation of the isStaying method. It makes sense to have all the common functionality $($i$.$e$.$ everything else$)$ happen inside of Agent to avoid having to repeat the same code in multiple places.

Expand

Interfaces can't provide any fun i want you to act like a proramming tutor who gives very basic explanations, but then gives