As a beginning programmer, I didn't understand the importance of design principles. I just wanted to make my programs work. That's why I learned to program in the first place, after all--I wanted the product. Now as I look back on some of my early code, I see how terrible it is. At this point, I've become interested enough in programming that I want the code itself to be of high quality, apart from whether or not it works. And ultimately, I will be able to produce programs more easily for myself if I invest time in making good code from the beginning, because more of my products will be reusable.
In this set of readings, we are going to use the game of War as a case study in design. If you have ever spent some time with a seven-year-old (particularly on a rainy day), you may have been lured into a card game known as War. This game depends purely on chance, with no element of strategy whatsoever. It also takes forever to end! Parents do things like removing some of the cards to speed up the game. I started wondering just how long it takes the game to end, on average. Could it theoretically go on forever? (I do think about these things. It's a sickness.) I decided I needed a computer program to simulate the game for me and count how many tricks each game took.
As driven as I am to get my hands on the product, the Game Of War Simulator, I want to do it right this time. And I am going to make you suffer through the process with me. I hope to help you avoid developing some of my bad habits. We will be applying the important design principles I have been learning about as I improve my programming skills.
In commercial software design, projects begin as "problem statements." The customer expresses what problem the computer program is supposed to solve. It is probably a fairly complicated problem which contains lots of different requirements. The customer lists those requirements and the software engineers will find a way to meet them. I saw one example about a program to run elevators in a building. One requirement listed in the problem statement is that when the request button on a floor is pressed, the elevator travels to that floor. That certainly is one of the things we expect an elevator to do. The problem statement needs to list all of those requirements.
For our problem statement, let's just start out with trying to make the game itself and then later build it into a simulator that plays multiple games. The problem statement for our game of War could be fairly simple, actually, since there aren't too many different scenarios to worry about. I took this description of the game from a card game site:
In the basic game there are two players and you use a standard 52 card pack. Cards rank as usual from high to low: A K Q J T 9 8 7 6 5 4 3 2. Suits are ignored in this game.
Deal out all the cards, so that each player has 26. Players do not look at their cards, but keep them in a packet face down. The object of the game is to win all the cards.
Both players now turn their top card face up and put them on the table. Whoever turned the higher card takes both cards and adds them (face down) to the bottom of their packet. Then both players turn up their next card and so on.
If the turned up cards are equal there is a war. The tied cards stay on the table and both players play the next card of their pile face down and then another card face-up. Whoever has the higher of the new face-up cards wins the war and adds all six cards face-down to the bottom of their packet. If the new face-up cards are equal as well, the war continues: each player puts another card face-down and one face-up. The war goes on like this as long as the face-up cards continue to be equal. As soon as they are different the player of the higher card wins all the cards in the war.
The game continues until one player has all the cards and wins. This can take a long time.
This description of the game can be considered our problem statement, because it tells us all of the requirements for our program.
To move to the next phase of development, let's turn the problem statement into comments. That's right, I mean java comments that you write with //. I'll help you get started:
public class GameOfWar{
//start with standard deck
//shuffle deck
//deal out 26 cards to 2 players
...
}
Eventually, these comments will either be turned into java code statements, or they will remain in the program as comments that explain sections of code. When variables and methods have sensible, descriptive names, it's easy to translate the comments into code:
public class GameOfWar{
void playGame{
DeckOfCards theDeck = new StandardDeck();
theDeck.shuffle();
...
}
}
As you can see, the comment that originally said "shuffle deck" is now a Java statement: "theDeck.shuffle()". You will work in two groups. Go ahead and start a class GameOfWar and put in all of the comments needed for a full game. Then we will proceed to the next stage, testing.
| Course Home Page | Next Topic |