OOP Design Quesiton with a Card Game

3
votes

I am becoming a bit more confident with my programming skills, so I've decided to restart a card game I'd previously began. The point of this program is now that I have a decent grasp of program flow, variables, conditions and so on, I want to deepen my understanding of OOP

So I need some advise on object oriented design

My card game will have 5 classes:

  1. Main
  2. Card
  3. Deck (has-a Card ArrayList)
  4. Player (has-a Card ArrayList of Card objects received from a Deck object)
  5. Dealer

I am wondering if it would be proper OOP to make the Dealer class an interface. All players should be able to play the role of dealer, but needless to say, there is only one dealer per round of cards. Is it ok to make the Player class implement the methods a dealer can perform (such as dealGame()) even when 7 out of 8 Player objects in any given round won't be making use of their implemented methods, and furthermore, are NOT TO BE CONSIDERED A DEALER at the time? Or would it be better to make the dealGame() method belong to the Deck class and call the deck to deal a game? Sorry if this is a dumb question, but I'm a bit sketchy on the principles of OOP and want some advise to learn to do it right the first time.

I also thought of making Dealer extend Player but I think that would be wrong because I need players to assume a role of Dealer on the fly, rather than be declared as a Dealer object in an unchangeable fashion. In this case - if Dealer extends Player - I think I would need to declare all players of the game as Dealers.

So basically I'm asking:

  1. If you were making a card game with these 5 classes, would you make the Dealer class an interface and the rest regular classes, and why or why not?
  2. Am I generally on the right track with OOP or am I completely lost?
3
javaclassoopinterface
You seem mostly on the right track. I'm not sure about the Dealer class though. Perhaps a better idea might be a Game class, that keeps track of meta-stuff. It handles the actual dealing of the cards from the deck, keeps track of which players have folded, etc., and which player is the dealer, keeps score, etc. - nhgrif
I know in real life a player deals, but is that actually nessissary within this simulation of real life? I mean is the players identity as a player in any way connected with their identity as a dealer - Richard Tingle
For me, methods such as dealGame() belong in some other, game-related class. A player being a dealer or not would be just a matter of a boolean flag, which would give them permission to call those methods on some kind of Game or Table object. - Maciej Stachowski

3 Answers

4
votes

You have good approach, however still some work to do :). All the classes are fine, but Delaer is NOT.

First - if player is dealer one round and second someone other is dealer, I dont see a point of extended class or an interface.

In fact, for beginning, I would not make any player a dealer, it makes things complicated.

The easiest and best way how to deal with this, is create 5.Game. Game has Deck and all the players and it is working similar as dealer. It waits for players to response, it shows cards when it should etc.

If you really want make players as dealers it will be more complicated :). Well you need the Game class as well, because the Game has to decide who starts as dealer and it should took away or give players the dealers rights (well I dont see the point of it, but if you want... :) ).

And how to do that? The Game has Player dealer variable. If should have something like registerDealer(Player player) method. Then you need some kind of interface to communicate between Game and Player. If you want for Player to have ALL THE RESPONSIBILITY for Game, you can use Visitor pattern. (it allows dealer to "sneak" inside game instance and do whatever public methods can do).

Otherwise, you can just let the Game to ask dealer what to do and wait for players input. It should be done by calling method like dealer.askWhatToDo() and using returning value for action. It allows validating input... However if I am right, the valid input in poker is always only one, so I dont see any difference, if Game itself decides what to do...

The only reason I see is if dealer can shuffle the cards or raise the base or stuff like that, then it can be done... Or if you want simulate poker game with poker-players and dealers can do non-valid things like in real life :).

1
votes

It really depends a lot on how the program works, what you expect each class to be able to do, and how the life cycle of each object works (e.g can a player become a dealer in later rounds).

My first impression from what you wrote is that you need a base class "person" from which "player" and "dealer" inherit, but that's just a guess working off limited information.

1
votes

Dealer isn't really a special type of Player. It's just one instance of Player at a time that has special responsibilities. I think you're on the right track but you may want to create a class for the particular Game you're playing.

Let's say you're writing a poker game. The Dealer in that case can occasionally influence the order of play (depending on the style). But if you're playing War, the dealer is just someone who hands out the cards and you really don't care. In that case the concept of "who's the dealer" and "how should the dealer deal the game" are responsibilities of the game itself, not the player.