Step 1: View chess as a system
Chess is a game played by two players on an 8X8 board whose squares alternate in color. Each player has 16 pieces that may be either all black or all white. There are six kinds of chess pieces: 1 king, 1 queen, 2 bishops, 2 knights, 2 castles and 8 pawns. Chess is a turn-based game where each player can move a piece a certain number of squares in a certain pattern depending on the specific piece. A player may capture an opposing player's piece by legally moving onto the square occupied by the opposing piece. If the king is in jeopardy of being captured, we can say that the king is in check. If the king is in check, he must move or somehow situate other pieces so that he is no longer in check. The goal of the game is to force the opposing king into checkmate. This is done by positioning pieces in such a way that the opposing king cannot get out of check.

Step 2: Identify the participants
Who are the participants of this system? What objects do we intend to model? When flushing out objects, a common trick is to underline all the nouns in the system description. When we do so and aggregate all of the common objects (i.e., 64 pieces instead of 1 King, 1 Queen...), we have:

Step 3: Model the states, identities and behaviors
Let's start with the pieces, the pawn in particular. A seasoned OO developer will notice that we are making a mistake here, but for those less experienced, just press on. A very important OO principle will emerge from our error.

What states can a pawn have? It has a color, a position, is it dead or alive? Is it in jeopardy of being captured by another hostile piece? A pawn has an owner (a Player) How about behaviors? A pawn can move, a pawn can capture and a pawn can die. Pretty straightforward.

What about identity? There are 16 pawns per game. The difference between any two pawns is not an identity difference and not a behavior difference, but a state difference. That is to say that a pawn is a pawn. Any two should be identified as pawns, regardless of which team they belong to or their position on the board. Any two pawns will also have the same behaviors (they move according to the same rules, they capture the same way). We can say that the difference between any two pawns is really a state difference. They might have different colors or different positions or different owners. Object-oriented languages provide us with a mechanism to describe these general models - a class. Using a class, we can create one model of a generic pawn that expresses all of the possible states and behaviors of any pawn. Once we have a pawn class, we can create as many pawn objects as we need. Think of a class as a blueprint. With a blueprint for a house you can build several houses (several house objects). Each house object can have a different color or different appliances (different states). The blueprint (class) will only indicate that there is a spot for appliances in the kitchen, or the walls can have a color. The blueprint describes the possible states; each object maintains its own particular state. In OO vocabulary, we would say that a pawn class has 16 instances.

Actually putting the model on paper in Java is a fairly straightforward process (see Listing 1). Once the class is created, we can create an instance of the class by declaring a variable of type pawn and calling new on it. So in some other part of the program, perhaps in our Player class, we might have code that looks like Listing 2. Notice how we create our Pawn class once and we can create several instances of it. Remember, the class declaration is only the blueprint. The instances are the actual objects that will maintain distinct states (positions, colors, life status, etc.).

Once the Pawn class is created, we should move on to the other pieces. Let's model a Queen. Answer these questions to yourself: What are the possible states of a queen? How about behaviors? Really try to answer them and read on only after you have thought about it.

Interestingly, a Queen and a Pawn have the same behaviors and states. As a matter of fact, If you model a Castle or a Bishop or any piece, you will find that they have the same behaviors and states. Only the identities are different. This is an Important part of OO: finding commonalities of objects. So, since we have done the work of modeling one piece (the Pawn class), we can make a few minor changes and have our one class represent any piece. Namely, we have to change the name of our class from class Pawn to class Piece. Our Player class will change too. Take a peek at Listing 3.

Once we recognize that all pieces are basically the same, we have to ask ourselves the question: What makes pieces different from one another? If you think about it, the primary difference is that pieces have different legal moves. A Pawn and a Knight move differently. You will notice that I have included a legal move behavior in the sample code but commented it out. We need to know a little more about OO in order to be able to make a decision as to whether we should include this method. We have to make a design decision.

Who among the participants of this system knows which moves are legal for a particular piece and which are not? Does each piece know? A player? The board? The game logic? Keep in mind that we are modeling a system, and the system is a real world system. In a real chess game, the players know which moves are legal because the players know the rules. A good OO model of chess should reflect this relationship. If you were to write this program, you should defiantly make legal moves part of the game logic (and keep in mind that a Player will know the game logic ) section of the program and not the individual pieces. It is a wise rule of thumb to keep the OO model as close to the real world model as possible.

However, in our case chess is an example. We are using it to illustrate some key points about OO. For our purposes, let's make each piece smart enough to know whether a particular move is legal or not. In other words, each piece will have a behavior that can determine whether a particular move is legal for that piece. A pawn will know if a move is legal for a pawn, a queen will know whether a move is legal for a queen, and so on.

How do we do this? If we add the logic needed to determine whether a Pawn's move is legal to class Piece, will we have to create new classes for Queen, King, Castle, etc. and redo all the work we have put into our piece class? We will have to rewrite all the other behaviors (i.e. setColor, getColor, etc.) and all the other states. Wouldn't it be great if we could build on class Piece and add some new behaviors or states? Well, we can. OO provides us with a mechanism known as inheritance. Inheritance allows one class to assume the states, identities and behaviors of another class. We already have a class Piece, which will be our base class or parent class. The goal is to create new classes, such as class Queen and class King, that add the logic specific to those pieces that can determine if a move is legal.

We will define the legalMove method in class Piece as being abstract. This means that we will not provide an implementation for the method in this class, only the behavior declaration (i.e., public boolean legalMove(Position p)). Furthermore, abstract means that we can not create an instance of class Piece, and any class that inherits class Piece must provide a method body (provide logic for), the moveTo method. Look at Listing 4 for some code examples.

In Listing 4, we have created a Queen class and a King class that extend (inherit from) the abstract base class Piece. Because a King and a Queen extend piece, they still have the same behaviors and states as a Piece. That is, a King can still setColor or moveTo. Same for the Queen. There are only two differences: 1. The King and Queen class implement their own legalMove methods with logic specific for that piece.
2. Instances of the King and Queen class can be identified as a Piece.

Remember, that first line of the class declaration indicates the identity(s) of the class. Whenever we use inheritance and the extends keyword, we put more than one identity on that line.

"That is it for today, class," says John. "Your assignment is to consider the following: All animals have some common behaviors. Animals have to eat, breath, drink, sleep, etc. However, the way particular animals actually do these things differs greatly. For example, both a human and a dog can run, but they do it in a completely different way. Think about how you would model some different animals in Java. You might have a base class Mammal that defines some common behaviors, and classes such as Human and Canine would implement specific behaviors. Try demonstrating this concept on paper. Afterwards, think of some other systems where inheritance might come into play."

"More Homework?" one student grumbles to another. "Yeah, but John doesn't want us to submit this one to him. He says he was swamped with e-mail from the last class." "So why bother doing it?" "Because we will probably need some practice before the next class and besides, we can always e-mail questions to him. He just doesn't have a TA to grade the assignments."