Introduction

Java is a general-purpose language, equally suitable for developing games as developing an income-tax calculation and filing program. As such, Java's data-modeling mechanisms are very general and low-level.

Java, as nearly all programming languages do, recognizes different kinds of data. A number is one kind, a word is another, an image is another. The formal name for “kind” is type. Every piece of data handled by your Java program belongs to one type or another. In fact, one way to understand the concept of “type” is that a type is the name of the set of data values that belong to it.

This unit is devoted to studying the different mechanisms Java offers for modeling the data types your program is built around. There are only four core mechanisms. You will create your own types using these four mechanisms. These mechanisms constitute Java's “type language.”

Decomposition

Given the task of writing a program that can represent a game, it can be a little daunting knowing where to begin. This feeling of wondering where to begin is actually pervasive in the programming process. So it helps to have a mechanism, a trick, to apply to the where-to-begin problem. The most common trick in computer science is decomposition.

You begin The decomposition process with a plain-language statement of what a game's state consists of, and then progressively break that down, using the data modeling mechanisms of Table Java Data Modeling Mechanisms, until there is no more decomposition that can be done.

For example, here is a plain-language statement of the game-state of a game of Blackjack. There are the cards that have been dealt to each player, the cards that have been dealt to the dealer, and the remainder of the cards in the deck. There is also state of who is dealt the next card.

We'll do a quick example of decomposition. How do we model a deck of cards, or a hand of cards? Let's take the deck first. A deck is a collection of cards. The array is the best choice for this, since all the elements of the collection are the same type, whatever that type is with which we will model a card.

How do we model a card? A card is a collection of two things, one called “suit” and the other “rank.” The fact that we can name the parts of the collection leads us to model a card using a class.

Now how about suit and rank themselves? A suit is one of four values: Spades, Hearts, Clubs, and Diamonds. This leads us to an enumerated type. Rank is similar, with Ace, 2–10, Jack, Queen, and King. We can use an enumerated type for rank as well.

As to how to model who is dealt the next card, we can use a number. The number 1 can represent the first player, the number 2 can be the second player, and so on.

Done! To summarize it in the vocabulary of Table Java Data Modeling Mechanisms, which is all we can do at this point:

The game-state of the game of Blackjack consists of:

• An array of cards to represent the deck.
• An array of cards to represent the dealer's hand.
• An array of array of cards to represent the players' hands.
• card is modeled as a class consisting of suit and rank fields.
• suit is modeled as an enumerated type with the values Spades, Hearts, Clubs, and Diamonds.
• rank is modeled as an enumerated type with the values Ace, 2–10, Jack, Queen, and King.

Notice that the model for the deck referred to card, which had not been defined yet. You had to wait until the fourth bullet to know what the card model was. And even then, it was defined in terms of two things, suit and rank, that weren't defined until the fifth and sixth bullets. The order of the definitions doesn't matter; it only matters that there are no missing definitions. This is true in the Java type language as well.

We believe that if you define a clear and complete data model for your game state, the rest of the coding is a lot easier. This section is about learning the Java type language for defining data models such as the one above.