How to Create a Deck of Cards in OOP Without Dynamic Memory Allocation?

[Saladsamurai]

I decided I would try to create a relatively simple class in order to gain some more experience with thinking in an OOP mindset. But some things are hanging me up. I want to create a class of objects that represent a deck of cards. The number of cards should be able to change depending on what the user wants to do. A simple function that I will implement will be used to shuffle the deck. I figured to do this, I will use a vector object as the deck and then add some additional functionality to it. I am a little confused as to what the best way to do this is. I always hear that dynamic memory allocation is not good (when it can be avoided). This is presenting me with difficulty since I want to be able to initialize the Deck size.

How would you do this? Would you have a member function that takes in the number of cards as a parameter and then initializes the deck with it? Or is there a better way?

 

[Greg Bernhardt]

Who's down with OOP? yeah you know me!

 

[Stephen Tashi]

How would you do this? Would you have a member function that takes in the number of cards as a parameter and then initializes the deck with it? Or is there a better way?

If you are doing this as an exercise in Object Oriented Programming, I suggest you put the initialization process in the constructor of the class rather than equipping the class with a function that must be called to initialize the deck. Generally speaking, an object should be ready to use after it is instantiated.

 

[Saladsamurai]

If you are doing this as an exercise in Object Oriented Programming, I suggest you put the initialization process in the constructor of the class rather than equipping the class with a function that must be called to initialize the deck. Generally speaking, an object should be ready to use after it is instantiated.

Hi Stephen Yes, this is what was bothering me ... the whole ready for use thing. The problem I am facing though is that the deck size is up to the user. So either way, I need to pass a value to the object in order to set its size. I am a little new to the lingo as well. When you say:

<snip> I suggest you put the initialization process in the constructor of the class rather than equipping the class with a function that must be called to initialize the deck

Do you mean that I should create an object class such that when I go to my main() fuction (c++) I can pass it an initialization parameter like this?

#include<Deck.h>

int main()

    int n(500);
    Deck myDeck(n);
    // code ...

return 0;

 

[AlephZero]

I suspect you are trying to figure out how to implement something (your "deck of cards"), before you have really got your head around what the "something" is. (Don't worry about it - that's a very common beginner's OOP problem!).

Also you can't really design one class in isolation from everything else. I would start by designing a "card" class that represents one card. It probably doesn't need to do much, for example
- know which unique card it is
- be able to print itself
- if you make a graphical interface, be able to draw itself.
- know how to compare the "value" of two cards, following the rules of your game.

Then, your "deck" will be some sort of collection of "cards". Whether the best sort of collection is a vector, or a list, or something else, will depend what you want to do with the "deck".

In a typical card game, there will probably be "players" with "hards" of cards, and possibly other "interesting" sets of cards as well. It might turn out that a "deck" is actually a special case of something else...

 

[Stephen Tashi]

Do you mean that I should create an object class such that when I go to my main() fuction (c++) I can pass it an initialization parameter like this?

#include<Deck.h>

int main()

    int n(500);
    Deck myDeck(n);
    // code ...

return 0;

Yes, that's what I mean. You can also study how to prevent someone from using the default constructor (which has no argument n) for Deck. I haven't written a C++ program in several years and I've forgotten the good way to do that, but it's in many books.

I agree with AlephZero that you can't make realistic design decisons about a class unless you understand how the class will be used. My suggestion isn't based on a rational vision of what the requirements for the class Deck are. It's just based on the statistically most common way to write classes, which is probably the first thing you should practice.

The architect Christopher Alexander is credited with inspiring many ideas about computer programming. I'm unsure whether ever wrote anything about computer programming per se. His Phd. Thesis is interesting. It's probably available on the web. The main point I took away from reading it is that it is important to identify goals in the design process that tend to be contradictory. For example, designing a simple object like a tea kettle might have the goals of "Be sturdy" and "Be lightweight". Given the nature of most materials these are somewhat contradictory aims. Alexander says that outstanding designs are often perfect compromises between somewhat contradictory goals or surprising configurations where two contradictory aspects are accomplished in some harmonious way. Hence, it is important to identify the goals of a design that tend to be in harmony or conflict. With designing classes, you've already encountered the conflict between efficiency and convenience.

If you want to study design (of computer software or anything else), you'll have to do it in a realistic situation where there are definite goals - I don't mean a laundry list of specifications, I mean general goals that you have freedom to meet in various ways.

If you want to study the syntax of programming and the nuts and bolts of how classes work, don't fret too much about design problems. Just start coding. For example, you could write a class Deck and then study how to extend classes by inheritance.

An important practical skill in all the OOP is how to cut-and-paste effectively. There is so much boilerplate-like stuff to write!

 

[I like Serena]

There's nothing wrong with a method that sets the deck size.
Just try not to do dynamic allocation yourself, but try to let the library do the work for you.
So use for instance:

class Deck
{
public:
   void setDeckSize(int n) { m_cards.resize(n); }
private:
   std::vector<Card> m_cards;
};