Classes and Organization
Author
Alright, some of you may know I'm working on a card game (C++) and I'm doing my best to use classes and sort everything out logically but everything is starting to get entangled which is causing me to have to really work things out in my head, thus slowing me down.
This is what I have so far:
Card Class: Holds information on the card
Player Class: Holds a hand (of Card Instances) and player information
Shoe Class: A standard deck (of Card Instances)
Dealer/Game Class: Deals cards and keeps track of bets/hands/win situations
So everything works fine, but at the moment I feel really disorganized.
The Player class needs to include the Card class (so it understands the instance type) and the Shoe class also needs the Card class. The Dealer class needs the Player class included so it can use the class instances and it also needs the shoe class so it knows which deck to draw from.
How can I better organize myself in terms of number of files, names of files, what is in them, and how they are organized. Am I doing something wrong if one class needs to know about another one? The only reason I have it the way I do is because the deck and player classes act completely independent of each other and so the dealer/game class is the glue and middle man that will draw a card and give it to the proper person.
Thanks much.
My personal technique is to draw things out before hand. My tools for initial inception are simply pencil and paper. I hate Viso, but I do use it to do more advanced modeling. I would suggest learning the basics of UML, even if you decide to create your own modeling syntax.
Drawing things out will help you to visualize how data is being passed around. It seems you have a pretty good idea of the local data in your head, but a visual representation may help you to keep things straight.
Best of luck!
Drawing things out will help you to visualize how data is being passed around. It seems you have a pretty good idea of the local data in your head, but a visual representation may help you to keep things straight.
Best of luck!
No, your design sounds good to me.
-- The Card class can sort of stand alone... it doesn't need to know about anyone.
-- The Shoe class needs to reference the card class, so it can hold a list of 52 card instances (or whatever) for the deck.
-- The player class needs to reference the card class, so it can hold pointers to the card instances.
-- The dealer class needs to reference everyone, because it should have a list of players and a shoe, and will probably need to reference cards when pulling them from the shoe and giving them to the player...plus the dealer will have to do some card logic (which might belong in the card class, but probably with the dealer so that you can inherit it to have a PokerDealer and a BlackjackDealer, etc, each with its own game logic).
If you start seeing circular references (e.g., the Card references the Player and the Player references the Card), then you may want to rethink your design, but even that isn't always a problem.
-- The Card class can sort of stand alone... it doesn't need to know about anyone.
-- The Shoe class needs to reference the card class, so it can hold a list of 52 card instances (or whatever) for the deck.
-- The player class needs to reference the card class, so it can hold pointers to the card instances.
-- The dealer class needs to reference everyone, because it should have a list of players and a shoe, and will probably need to reference cards when pulling them from the shoe and giving them to the player...plus the dealer will have to do some card logic (which might belong in the card class, but probably with the dealer so that you can inherit it to have a PokerDealer and a BlackjackDealer, etc, each with its own game logic).
If you start seeing circular references (e.g., the Card references the Player and the Player references the Card), then you may want to rethink your design, but even that isn't always a problem.
In my opinion, the player's "hand" and the "shoe" should either be the same class or derive from the same class. Both are collections of cards.
Quote:Original post by ItsDanBeyond the fact that they are both going to be stored in a std::vector or something similar, that's not true. The Shoe certainly manages an ordered collection of cards, but it also contains a lot of logic for managing the cards.... how to shuffle, how to deal, how often to pull a new deck, etc...
In my opinion, the player's "hand" and the "shoe" should either be the same class or derive from the same class. Both are collections of cards.
The players hand is also a collection of cards, but isn't necessarily ordered. It is a member of Player anyway... I don't think the intent was to have a class specifically for the "hand", but for the player--which will have a collection of cards as a data member.
Quote:Original post by smitty1276Quote:Original post by ItsDanBeyond the fact that they are both going to be stored in a std::vector or something similar, that's not true. The Shoe certainly manages an ordered collection of cards, but it also contains a lot of logic for managing the cards.... how to shuffle, how to deal, how often to pull a new deck, etc...
In my opinion, the player's "hand" and the "shoe" should either be the same class or derive from the same class. Both are collections of cards.
The players hand is also a collection of cards, but isn't necessarily ordered. It is a member of Player anyway... I don't think the intent was to have a class specifically for the "hand", but for the player--which will have a collection of cards as a data member.
Well if you believe in the concept of small, specialized, specific purpose classes it might be prudent to separate the random player info such as name, score, etc, from the collection of cards.
I can see enough similaring between shoe and hand to atleast have a common base class, if not literally the same class. Adding, removing, shuffling, 'pop'ing, and other such functionality would seem appropriate for a base class.
It's obviously a design decision though, certainly not saying it's wrong to have them a distinct class/class elements.
Dont players get their cards from the deck?
I would have the Player class query the Shoe class (It is
a manager of the entire deck, correct?) for a random
collection of cards.
You can also make the cards pointers that point to the respective
cards in the whole deck[smile]
This way...
I would have the Player class query the Shoe class (It is
a manager of the entire deck, correct?) for a random
collection of cards.
You can also make the cards pointers that point to the respective
cards in the whole deck[smile]
This way...
[Card class] | [Shoe Class] | |[Player Class] [Game Class]
Author
Yeah a shoe, in terms of cards, is no more than multiple decks used in play. In some cases (depending on the game and style) the shoe will be one deck anyway.
In my case, the shoe class can be named the deck class, either way it is the same thing. I have a default constructor that makes one deck and then one with a int parameter for multiple decks.
I've re-written my the player class. Right now, it is a card stack class that handles a basic grouping of cards (for say any kind of community cards, or if you are playing solitaire for example). Then the Player class inherits from that and simply adds the players information to the mix. Since both share push and pop functions, they are extremely similar as some of you mentioned.
Anyway thanks for the tips. Does it make sense to break the classes off into a .h file and a .cpp file or should I just keep them all together? What warrants using an .h and a .cpp for one class?
In my case, the shoe class can be named the deck class, either way it is the same thing. I have a default constructor that makes one deck and then one with a int parameter for multiple decks.
I've re-written my the player class. Right now, it is a card stack class that handles a basic grouping of cards (for say any kind of community cards, or if you are playing solitaire for example). Then the Player class inherits from that and simply adds the players information to the mix. Since both share push and pop functions, they are extremely similar as some of you mentioned.
Anyway thanks for the tips. Does it make sense to break the classes off into a .h file and a .cpp file or should I just keep them all together? What warrants using an .h and a .cpp for one class?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
