在确定21点游戏的Java代码中执行哪个类的方法时遇到问题。 非常基础，是编程新手

Question

I'm attempting to make a simple Blackjack game written in Java and consisting of a Blackjack (Tester), Card, Deck, Dealer, Player, and Game class.

My code is still very much incomplete, but I'm having difficulty determining, once I've created a deck of cards, which class I should be dealing the cards in and how I should be storing the Card objects in both the player and the dealer's hand (arrayLists).

For example, I thought I could solve the issue by using hand.add(deck.draw()); to the player class, thereby adding the Card drawn from my array cards to the arraylist hand. However, in order to do this I have to create a deck object in my player class, which is then different than the deck object that I create in my Game class. However, if I draw the card in the Game class using deck.draw(), I'm unsure of how to take that value and store it in the arraylist hand within my Player class.

Hopefully this is making sense!

Essentially, my question is if I use my deck.draw method in the Game class which returns a Card, how do I then take that Card and store it in my private arraylist hand in the Player class? Or is this the wrong approach entirely?

Thank you for any guidance you can provide!!!

Answer 1

First, seeing your code before your edit, I wanted to point out that I think you're doing pretty well for a new developer,keep at it!

I think you simply should keep following the path you're on...you've used domain language to name you're model (Deck, Card, Dealer, etc) and you've got a good start in naming the behavior of those classes based on the model too (draw). Stick with this...

Anyway, hope this helps below...it's pseudo-code (in this case, my way of saying I didn't write this on an IDE and I didn't validate the code...but it should be quite close) =)

Dealer should manage the Deck, so there should be an aggregate relationship there. Since the Dealer has the instance of the Deck (the Deck is backed by an array and its position is recorded by an int, no need for a Collection type) length of 52). On construction, the 52 Card instances are added to the array. The Deck indeed had draw, which increments the card position and returns the Card.

//this interface will make sense a little later
public interface HandManager {

    Card draw();

}

public class Dealer implements HandManager {

    private Card[] deck;
    private int position;

    @Override
    public Card draw () {
         try {
             return deck[position];
         } catch (ArrayOutOfBoundsException ex) {
             //handle when you run out of cards in your deck...do you add another 52?
         } finally {
             position++;
         }
    }
}

The Dealer also has a draw method, that takes just a vararg on players (and deals he initial Hand to all players).

//also in Dealer
public void deal (Player... players) {
    for (Player p : players) {
        Hand hand = initializeHand(); //we'll get back to this in a bit
        p.addHand(hand);
    }
}

Meanwhile, the Player aggregates the Hand....they own and decide what they want to do with it. The Hand shouldn't really be a simple array because it should be able to easily grow, so a List or Set should do (a Set is probably more appropriate in theory...but because you probably don't need to enforce uniqueness here, there isn't need for that overhead really). But...to future proof it, so you can change it to a Set later if you want, you should program to the Collection interface (you should always try to program against the highest super class if you can, better for code maintenance).

public class Player {
    private Hand hand;

    //can be named "setHand" if you only want to support one Hand per player, named 
    //like this because it might be a fun exercise to enable n hands per player later
    public void addHand (Hand hand) {
        this.hand = hand;
    }
}

public interface Hand {

/**
 * Returns the cards currently in the hand.
 *
 * Changes to the returned array are <b>NOT</b> reflected in the hand.
 */
public Card[] getCards();

public void hit();

public void split();

public void fold();

}

Anyway, player acts on Hand, decides to hit, split, fold, etc. The neat thing here is that, in theory, a Player can mange n hands this way ;) Anyway...here is where some magic comes in which will keep your code cleaner: the 'communication' between Player and Dealer happen through the Hand instance. This allows Player to call the shots, but more importantly, allows your applications orchestration to focus not on passing commands from player to dealer and card from dealer to player...but the aspect it needs to: managing the turn based play and knowing when to end the game.

public class ManagedHand implements Hand {

    private Collection<Card> cards;
    private HandManager manager;

    public Hand (HandManager manager, Card[] cards) {
        this.manager = manager;
        cards = Arrays.asList(cards); //to make this a set, simply pass this into a HashSet constructor =)
    }

    /**
     * Returns the cards currently in the hand.
     *
     * Changes to the returned array are <b>NOT</b> reflected in the hand.
     */
    public Card[] getCards() {
        //bonus lesson: look up "defensive copy"
        return cards.toArray(new Card[cards.size()]);
    }

    @Override
    public void hit() {
        if (isBust()) {
            throw new BustException("Need to wait for next hand!");
        }
        //***RIGHT HERE, Dealer (the HandManager) gives the card on draw request****
        cards.add(manager.draw());
    }

    @Override
    public void split() {
        if (isBust()) {
            throw new BustException("Need to wait for next hand!");
        }
        //do split...beyond demo code scope =)
    }

    @Override
    public void fold() {
        //clean up, take money/car/happiness
    }

    @Override
    public String toString() {
        //pretty-print the current hand
    }

}


//the initializeHand method is Dealer that I promised
public Hand initializeHand() {
    Card[] initialHand = new Card[INIT_HAND_SIZE];
    for (int i =0; i<INIT_HAND_SIZE; i++) {
        initialHand[i] = draw();
    }

    //****Dealer registers itself as a HandManager to the Hand**********
    return new ManagedHand(this, initialHand);
}

Since Dealer instantiates (creates) Hand, it had the opportunity to register a listener (itself, in this case) for Player actions on the Hand. Since the Player is given the instance of Hand, take action on the Hand...the Hand does the validation itself (ie checks if itself isn't bust before requesting more cards) in this implementation (just because it would be a more complex example to have Dealer do it) and the manager is "notified" when more cards are needed.

Side note: This could have been built out a little more, but in general, it kinda-sorta follows what is called the Observer Pattern . It might not be a perfect match for this pattern...but you should check it out...and read all about design patterns. Learning these early in your career, you'll quickly become a rockstar.

Answer 2

One approach would be to have a function in the Player class called something like AddCard

public class Player
{
    private ArrayList<Card> hand;

    public Player()
    {
        hand = new ArrayList<Card>();
    }

    public void AddCard(Card aCard)
    {
        hand.Add(aCard);
    }
}

Answer 3

Since the cards in a player's hand have no inherent order to them, I think it makes more sense to use some kind of Set (such as a HashSet to store them) than an ordered structure like an ArrayList . I might write something like this. You'll see I've assumed that the draw method of the Deck class returns null if there are no cards left.

public class Player {
    private Set<Card> hand;
    private String name;

    public Player(String name) {
        this.name = name;
        this.hand = new HashSet<Card>();
    }

    public boolean takeCard(Deck toTakeFrom) {
        Card drawn = toTakeFrom.draw();
        if (drawn != null) {
            hand.add(drawn);
            return true;
        } else {
            System.out.format("Sorry, %s, no cards remain in the deck.%n", name);
            return false;
        }
    }
}