Organizing classes for Blackjack game

Question

I have to write a Blackjack game for college using the Processing language. It has to be done in a strict object-oriented approach, so I can't make an object of a class in another class unless there is some connection.

We have to use a Player interface:

interface Player {  

  // This is the interface you are expected to implement for both
  // the computer controlled 'dealer' and the human player(s)

  // You can change the return types for any of the items in the interface.
  // You can also add arguments two the first two method listed below

  void twist(/* you can add an argument here */);               // This method should allow the player to add acard to their hand

  void updateValueOfHand(/* you can add an argument here */);   // Updates the the value of the cards the player has in their hand

  void stick();        // Called when the player does not want to take another card

  void updateScore();  // Updates the player's overall score (number of games they have won)

  int getValueOfHand(); // Getter method for the value of the cards the player has in their hand

  int getScore();      // Getter method for the player's overall score (number of games they have won)

  void showHand();     // Used to display the player's hand on screen

  void clearHand();    // Used at the end of a round to empty the cards in the player's hand

}

I have done a storyboard for the game:

interface Player
class Card
class Deck extends Card

class Computer implements Player
class Human implements Player

I am planning to have a class called ScoreTable where I can keep and show the scores and a Button class where I can draw the buttons.

What kind of classes should I have? Should I have a ScoreTable class which implements Player, and also a standalone Button class?

Answer 1

You are beginning to mix up the business logic with the user interface. You should (be able to) design a "game driver" class without regard to user interface. You want to keep your GUI code separate from your game logic code. And another OO paradigm is to create new objects separately and pass them into where they are used.

I see a Game class ( "Dealer" might be a better name) that handles the cards, deals them to players, etc. Then your ScoreTable class wires-up it's buttons to the Game methods. For example a "Deal" button's click event handler might be Game.DealCards().

pseudo code for the idea:

  Player me = new Computer();
  Player you = new Human();
  Game aNewGame = new Game (me, you); 
    // I'm imagining that the game creates the card deck internally
  ScoreTable theCasino = new ScoreTable(aNewGame);

  // inside ScoreTable constructor...
  DealButton.onClick += aNewGame.DealCard();

Suggestions

1. Classes and their interaction reflect real life. Write code that way. I.E. A "Dealer" deals "Card"s from a "CardDeck" to "Player"s. (Now I really like "Dealer" better than "Game" as a class name). Therefore the Game must have (references to the) Players, so we pass player objects into the Game constructor.
2. Think in terms of the ScoreTable only displaying the game, NOT actually playing the game. The Game class plays the game. Thus the ScoreTable must interact/communicate with Game to display what's going on.
3. Think of ScoreTable as telling Game what to do and Game does it. For example you click "Hit Me" (ScoreTable) and that fires the Game.DealCard() method.
4. BlackJackTable sounds better to me than ScoreTable for that class name.

Can i have a ScoreTable class which implements Player and a stand alone Button class?

Do not do this. Think in real-life terms to keep things straight. A ScoreTable is a Player? That does not make sense. A ScoreTable has to display stuff on the screen so it is (inherits from) a Window - whatever the appropriate class is in Java.

What kind of classes should i have?

I see a ScoreBoard class. Your diagram inspired the thought. The diagram directly suggests the class would have an array (of hands) each element of which holds the final score for both players. This data structure, then, maps clearly to your UI concept. I see it as a separate class because it keeps score for both players, so it is inappropriate to be inside the (individual) Player class. A Player might have his score (hand) for the current game, but not past games, and certainly not the past games of a different player.

*Your Other classes *

• Card
• Deck - it's an stack of cards, it is not a card. And I mean "stack" in the way it behaves.
• Human - a Player that is stupid (we're going to click buttons to tell her what to do).
• Computer - a Player that knows by itself when to hold 'em and when to fold 'em
• Game - the dealer essentially. Shuffles and deals cards.
• ScoreTable - displays what's going on. "Controls" the Game via button clicking, etc.
• ScoreCard - keeps history of past game results.