So, let's just be lazy and take the example pretty much directly out of the book! Creating bridge hands! (I don't even know how to play bridge).
Statement of Problem
Create a program that builds and prints bridge hands
Design and Implementation
Okay, so we should start with finding out about bridge. Can't write a program about it if we don't understand it! This is applicable to a wider range of things, whether you need to familiarize yourself with a genre of game you're not big on, or gene sequences. You can't just dive into stuff!
Bridge is played with a standard 52-card deck by 4 players. The players sit around a table with sides marked as compass directions (North, East, South, West). Bridge is a clockwise game, so whenever anything is done, its in order of NESW.
Just an aside, I learned this as the order when I was a kid when my South African teacher taught us his method. Never Eat Silk Worms. He also told us Naughty Elephants Spray Water, but the former stuck in my head much more clearly.
Anyway! One person is a dealer for each hand, with the person to the dealer's left shuffling the cards. The person to the right cuts the deck, and then the dealer can deal cards out, 1 at a time in order of rotation.
So we essentially need a way to create 4 hands of 13, then display each hand. Assuming the idea is to have this program evolve into a bridge-playing game, it would be good to think about the grand design. As a list of things we need to worry about, we have the suits and values, each combination of which makes a card, 52 of which make a deck, which itself needs to be shuffled, then distributed 4 ways. Then come the players, who will presumably be named, and are given the cards in rotational order. And further still, is the table, who's organization seems to be important for some reason. Dealer selection if nothing else.
From the above, we see the lowest level of object appears to be a card (Yes, the card has a suit and value, but those aren't entities, they're enumerations). So many cards in a deck, so many cards in a player's hand, what have you. So we need to represent this card, somehow!
Fairly simple as a class. The enums are a little unwieldy, but they're essentially the same as in last post. Each Suit has its own toString() method that returns whatever that suit is, and the same goes for all the values, with Jack returning "J" and so on.
Immediately underneath the enumerators, we have variables that will hold whichever enumeration some instance of the object will have, and these are initialized through the constructor immediately below that. Note that the constructor does take parameters! After the constructor, we have a generalized toString() method, and that just makes it so when you ask for the string representation of an object, it takes both the Suit and Value and squashes them together, as god intended.
Questions? Good, cause now we have a representation of a card, in the next step, I'll be moving on to making a deck of them. Wrap your heads around this first!
That's it for tonight.Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!
And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us.