CareerCup

A good approach would be using class diagrams. Lets analyze the problem.
A deck is a collection of cards; it has behaviors as shuffle, pop, push, sort etc....
All the behaviors can be implemented by differently in various ways and they can change later, so we want the interface to deck of cards to be separated from implementation. A handle-body idiom!

//NOTE: this is NOT a good diagram for understanding class diagrams.
  Card
-----------
value
suite
..etc..

Handle<>---------->Body
    ^                      ^
    |                       |
 Deck                 DeckData
----------               -----------
DeckData            friend Deck
shuffle()               DeckData(); 
pop()                   ~DeckData();
push()
..etc..

// separating the way a deck data is implemented gives an advantage of changing it without affecting interface
class DeckData{
	friend class Deck;
	DeckData();
	~DeckData();
	//other data members
};
class Deck{
	public:
		Deck();
		//define copy constr. and assignment oper
		~Deck();
	private:
		DeckData *d;
};

One main idea to have a deck as a set because, you are never concerned about order in a deck.