When Flash MX first came out, one of the first pseudo-OOP classes that I ever made was a deck of cards. The deck was just a data object (kind of a high level array) that stored objects representing playing cards. It could be shuffled, cards dealt, etc. It was intended to be the utility class underneath any card game that I may want to create.

The exercise was useful, because it's relatively simple, but illustrates how to plan an OOP application (or at least one aspect of an application). Recently, I've revisited my old class and updated it for ActionScript 2.0. I thought some people may like to see the process of planning a deck of cards in Flash.

If you actually get a physical deck of cards and look at it, you'll see that it's basically an array (queue) of cards (data objects). The smallest and simplest part of the deck is the individual card. So, let's start our design by defining the Card class.

A basic playing card has a suit and a value. Cards also normally have a fancy single-color design on the back of them. In some games or card tricks, the back-color of the card is important, so we may want to store that data as well. The Card class really just represents data, so it doesn't need to have any methods or events. We may want to define a toString() method just to make it easy to trace out the value of a single card in Flash. That pretty much defines the public aspects of our Card class.

Now, to the actual CardDeck. Like I was saying above, a deck of cards is very much like a high-level array. So, we'll probably have a property of the class that represents this deckArray. We'll also want to be able to check the length of the deck array, so we should give the CardDeck a length property.

For the methods of the card deck, we'll have to consider all of the things that you may want to do with a deck of cards. Also, some games (like 21) may use multiple decks. Other games (like poker) may or may not use Jokers, depending on the type of game. So, when we first create our deck of cards, we should be able to declare just how many decks should be included and whether or not Jokers should be included. We'll call that method "createDecks". We may want an "addCard" method to allow us to insert custom cards (maybe we just want one Joker, or maybe a player returned a card to the deck). Obviously we'll need "deal" and "shuffle". When the deck runs low, or the game starts over, we will want to be able to start with a full deck. So we should add a "refreshDeck" method to support this.

We may want to loop through the deck and look at the value of the cards or remove a specific card, so we should have "getItemAt" and "removeItemAt" methods.

Supposing that the back-color of the card is important, we should have a way to set the back-color for all cards in a deck, so we'll want a "setBackColor" method. If color is important, we may want to create a red and a blue deck separately, then merge them into one deck, so we'll need a "merge" method.

That pretty much covers the basic things you would want to do with a deck of cards. But what if you want to cheat or do a magic trick with a deck of cards? If you can do it with a real deck, you should be able to do it with a virtual deck, so we should support those methods as well. A few simple "magic" methods may be "getHighestCard", "getMatchingSuit" and "getMatchingValue". Want to get a flush every hand, just deal the first card and reference that card with getMatchingSuit() for the next four cards and you'll be unstoppable.

The CardDeck class could represent the deck of cards in the game, but it could also represent the individual hands that a player is holding. After all, a player's hand is just an array of Card objects (just like our CardDeck). So, we should have a few events that would either notify a controller that we're at the end of the deck, or can notify a view that a card has been added or removed. Our events will be "cardAdded", "cardRemoved" and "endDeck".

Finally, since the CardDeck is going to have to handle events, we can use Flash's EventDispatcher to mix in the basic event handling methods. This will add the following methods to our CardDeck: "addEventListner", "dispatchEvent", "dispatchQueue" and "removeEventListner".

I normally implement an interface called IEventDispatcher when I plan on having a class use the EventDispatcher mix in. So, our final diagram of the CardDeck application will look something like this:

Now, we haven't written a line of code. In fact, you wouldn't even have to know how to write ActionScript to create this class diagram. Or for that matter, you could take this exact class diagram and implement it in VisualBasic, C++, Ruby, JavaScript or whatever. The point is, we don't start a project by firing up Flash and wildly hacking out code. Instead, we took a few minutes to consider what we're actually making, how such a thing works in the real world, and plan the functionality we want our classes to have. It wasn't hard and didn't take long at all. But now we have a perfect blueprint to work off of.

Although this is extremely simple, you could take this diagram and have one developer create the Card class and have another developer create the CardDeck class. In a complex application, this kind of planning is essential. But even in this simple example, it's very useful. At this point if we think of anything else that we want to be able to do to the CardDeck, we only have to update our diagram. We won't have to change any code.

When it comes time to code, it will be simple to break this down into specific methods and properties. There will of course be a few private properties and methods not illustrated in our diagram. But that's fine. That's why encapsulation is advantageous in OOP. We can do whatever we want on the inside, as long as the public side of our classes stays the same.

If you want to see how to actually code these classes, check out the source files. If you have any questions, please post them in the comments.