3

My primary goal is to create a Euchre game in Python. Euchre card games are rare on the Linux platform, no matter the language or the desktop flavor of choice. For now I want to be able to just create a simple game like BlackJack or Rummy. My platform is Linux Mint 17, and I'm using PyCharm.

The thing that is stumping me beyond any obstacles I can think of is the design of the classes. In my mind I see classes such as these:

Deck (deck of cards) Card (a single card) Hand (series of cards) Player (person playing the game) Dealer (person dealing the cards)

More specifically, it's the actions of those classes that is bothering me. Actions that confuse me are:

  • dealer dealing the cards. does the Dealer remove the cards from the deck, or does the deck remove the cards?
  • player receiving cards. Does the player place the cards into the hand, or does the Dealer do that?
  • shuffling the cards. Is this an action performed by the deck, or does the Dealer do this?
Improve this question
1
  • 3
    I think you're waaay too concentrated on having only classes that represent objects in the real life. Yes, it helps and it's good, but in object-oriented design you can go beyond that. Having stuff like PlayerManager or DeckShuffler or HandRank or GameFlowInspector etc. is perfectly fine. Such classes represent things that don't really exist as objects in the real-world, but they help you better decouple and manage the rules and laws of the game.
    – Radu Murzea
    Commented Feb 23, 2016 at 11:47

1 Answer 1

Reset to default
4

If you're going to have a class to represent a collection, then the operations on that collection should be implemented as methods on the class. Then a client will call those operations.

So if you have a class called Deck that contains a collection of Cards, you will have a method called "GetTopCard" which returns the topmost card. The Dealer will call that method. Similarly, shuffling is a method on the Deck that the Dealer calls.

For a Dealer giving a card to a player, the Dealer object would call the Deck's GetTopCard, and would pass the returned Card object to the Player's AddCardToHand method.

You can change your design to get rid of the middleman (the Dealer) but its probably easier for you to keep him around as a mediator and as a place to store the game's state. It might make it easier for you to model the game with a Dealer class as well. For the future, having a Dealer object makes it easier to change your game so the dealer is on a remote server with each player on a mobile device or similar.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.