Welcome
Note
These lecture notes are a draft. We’re almost certainly not gonna get to all of this today. I’ll update them with what we’ve gotten to after class.
Announcements
Are you a new add to the course? You need to get in touch with me immediately if you haven’t already done so.
Back to TicTacToe
When we left off last class, we had the following code:
package tictactoe;
public class TicTacToeBoard {
private enum Space {
X, O, EMPTY;
public String toString() {
if (this == X) {
return "X";
} else if (this == O) {
return "O";
} else if (this == EMPTY) {
return ".";
}
return "WTFBBQ"; // this should never happen
}
}
private Space[] board;
public String toString() {
String string = "";
for (int i = 0; i < board.length; i++) {
string = string + board[i];
if (i % 3 == 2) {
string = string + '\n';
}
else {
string = string + ' ';
}
}
return string.substring(0, string.length() - 1);
}
public TicTacToeBoard() {
board = new Space[9];
for (int i = 0; i < board.length; i++) {
board[i] = Space.EMPTY;
}
}
public static void main(String[] args) {
}
}
and test:
package tictactoe;
import static org.junit.Assert.*;
import org.junit.Test;
public class TestTicTacToeBoard {
@Test
public void testEmptyBoardPrinting() {
// do some setup
TicTacToeBoard board = new TicTacToeBoard();
// test a value is what you expect
// two arguments: first: what you expect
// second: what you're testing ("actual")
assertEquals(". . .\n" +
". . .\n" +
". . .", board.toString());
}
}
This is a pretty common pattern, actually, where you write and test code in a driver class or method, then encode your test as a test case. This way, if you break something by accident later, you’ll discover it immediately before you move on.
Output legibility
Remember I made EMPTY toString itself as a single . (and update our test appropriately). Usually this sort of thing is a good idea – anything to make your life easier when reading your code (and its output) will pay dividends in the future, either to you or the programmer who’s reading your code in six months.
Schools, especially intro classes, are very misleading about the code lifecycle. You spend most of your time in school writing your own code. But in the real world, you spend far more time reading, modifying, and fixing others’ code. And once in a while, when you’re reading and debugging some particularly gnarly code, you’ll come to an awful realization: The programmer who wrote this mess was you, six months ago. Don’t let this happen to you!
Back to the driver
Let’s sketch out the driver so we know what we’ll need to do. How is a typical game played?
- The board is empty
- Players take turns until the game is over, that is
- one player wins
- or it’s a draw (tie game)
- Taking a turn means choosing a valid move (and updating the game state accordingly)
- The game ends, the result is announced
What might this look like in code? Here’s a first cut.
public static void main(String[] args) {
TicTacToeBoard board = new TicTacToeBoard();
try (Scanner scanner = new Scanner(System.in)) {
while (!board.isGameOver()) {
System.out.println(board);
System.out.println("Player " + board.getCurrentPlayer() + ", choose a move (0-8):");
int move = scanner.nextInt();
board.move(move);
}
System.out.println("Game result: " + board.getResult());
}
}
Notice that we don’t worry about various error conditions (like if the player chooses an invalid move); we’ll get to that later. Also notice we haven’t yet defined any of these methods. Eclipse will sketch them out for us if we want (demo in class) though notice that we of course need to implement them.
Also notice that we’ve divided the methods into observers, which return a fact about the underlying object but don’t change the object’s state, and mutators, which change something about the object. It’s good practice to put methods into one or the other of these groups, to help us reason about our code.
Let’s leave isGameOver() alone for now, and work on getCurrentPlayer() and move().
Ways to implement an observer
getCurrentPlayer() returns the current player as a string. We can either explicitly keep track of whose turn it is (in an instance variable), or compute it by looking at the board (if there are an equal number of Xs and Os, it’s X’s turn; if there are more Xs, it’s O’s turn). Let’s keep track explicitly for now by adding an instance variable and initializing it in the constructor.
private Space currentPlayer;
//...later, in the constructor
currentPlayer = Space.X;
Another observer
Let’s make sure we return it in our getter:
public Space getCurrentPlayer() {
return currentPlayer;
}
A mutator
And, at the end of every move, it should be the other player’s turn, so let’s encode that, too:
public void move(int move) {
if (currentPlayer == Space.X) {
currentPlayer = Space.O;
} else { // currentPlayer == O
currentPlayer = Space.X;
}
}
Note that this method, which changes the object’s state, does not return a value (it’s void). Often mutators are void, since you generally don’t want to mix mutation and observation.
Checking in the driver, it works, inasmuch as the players alternate.
Testing our mutator
We showed in the console that the player’s turn will swap back and forth after each move(). Let’s start by adding a test that captures this behavior:
@Test
public void testPlayerChangeAfterMove() {
TicTacToeBoard board = new TicTacToeBoard();
assertEquals("X", board.getCurrentPlayer().toString());
board.move(0);
assertEquals("O", board.getCurrentPlayer().toString());
}
And while we’re at it, why not a bunch of moves?
@Test
public void testPlayerChangeAfterMultipleMove() {
TicTacToeBoard board = new TicTacToeBoard();
assertEquals("X", board.getCurrentPlayer().toString());
board.move(0);
assertEquals("O", board.getCurrentPlayer().toString());
board.move(1);
assertEquals("X", board.getCurrentPlayer().toString());
board.move(2);
assertEquals("O", board.getCurrentPlayer().toString());
board.move(3);
assertEquals("X", board.getCurrentPlayer().toString());
// ..etc
}
OK, and since we’re getting crazy, how about we get move() working now, too? It’s only a one-liner:
board[move] = Space.X;
And test it in the console. Huh, there’s a problem. Now, I get it, most of you see the problem immediately. But that’s kinda on purpose here; some problems are easier than others to spot (and then fix). Sometimes they’re simple problems you just can’t see yourself; sometimes they’re more subtle. Instead of caveman debugging this one (you know, adding “printlns” everywhere, let’s try the debugger) so we can see what’s going on.
First, we must set a breakpoint! Double-click the “gutter” and create a small blue dot.
Then run under the debugger.
Note that we can escape using the “perspective” buttons in the upper-right.
Values are displayed in the upper-right; everything in scope is here.
We can “step” forward line-by-line. “over” means stay in this method; “into” means follow any method call in that line into another method; “out” means return to the calling method.
The second time through, we see that the wrong value is assigned to the board entry – whoops, we hardcoded it! Let’s fix that:
board[move] = currentPlayer;
And test it in the console with our driver.
And maybe some tests now too:
In-class exercise
@Test
public void testOneMove() {
TicTacToeBoard board = new TicTacToeBoard();
board.move(0);
assertEquals("X . .\n. . .\n. . .", board.toString());
}
@Test
public void testMultipleMoves() {
TicTacToeBoard board = new TicTacToeBoard();
board.move(0);
assertEquals("X . .\n. . .\n. . .", board.toString());
board.move(1);
assertEquals("X O .\n. . .\n. . .", board.toString());
board.move(2);
assertEquals("X O X\n. . .\n. . .", board.toString());
// and so on...
}
Again, (one of) the reason(s) we encode this stuff into tests is so that if we break something later, we’ll spot it immediately and have a working test case to debug with.
How about checking for the end of the game? In English, in isGameOver() we check to see if either player has won or if it’s a draw. If any of those are true, the game is over, otherwise it’s a draw. Similarly, our getResult() method needs to determine which player won, or if it’s a draw.
Stopping and thinking for a second: we can express our draw check in terms of our winner check. If neither player has won, and the board is full, then it’s a draw.
What does this look like?
public boolean isGameOver() {
return (isWinner(Space.X) || isWinner(Space.O) || isDraw());
}
How do we check if a player has won? If they have three in a row. We could hardcode this, for example:
private String getWinner() {
if (board[0][0].equals(X) && board[0][1].equals(X) && board[0][2].equals(X)) {
return X;
}
else if //...
}
but we’d have to do 2 * (3 + 3 + 2) if clauses, mostly copy-pasted, making sure we didn’t screw up the board index each time. That’s OK, I guess, but it fails to capture the patterns we’re looking for: rows, columns, diagonals. Maybe something like this would be better:
private boolean isWinner(Space player) {
// check rows
for (int i = 0; i < 7; i += 3) { // pick a row (starting at i)
boolean won = true;
for (int j = 0; j < 3; j++) { // check each square in that row
if (board[i + j] != player) {
won = false; // any one is not this player
}
}
if (won) return true;
}
// check cols
for (int i = 0; i < 3; i++) { // pick a column (starting at i)
boolean won = true;
for (int j = 0; j < 7; j += 3) { // check each square in that column
if (board[i + j] != player) {
won = false; // any one is not this player
}
}
if (won) return true;
}
// check diagonals
if (board[0] == player && board[4] == player && board[8] == player) {
return true;
}
if (board[2] == player && board[4] == player && board[6] == player) {
return true;
}
// maybe it would have been shorter just to do the eight cases individually!
// context matters.
return false;
}
Two notes: First, we could further condense the row/column checks with another inner for loop (though it’s not much cleaner); second, notice this is a version of the for loop pattern we talked about in a previous class, where we check a bunch of stuff: if it ever becomes true, then the method returns true, and if we make it to the end, the method returns false.
How about a draw? If either player has won, it’s not a draw. Or, if there are still empty spaces, it’s not a draw. Otherwise, it’s a draw:
private boolean isDraw() {
// has someone won?
if (isWinner(Space.X) || isWinner (Space.O)) {
return false;
}
// otherwise, is the board full?
for (Space s : board) {
// if any of them are empty, no, it's not full
if (s == Space.EMPTY) {
return false;
}
}
return true;
}
Notice I can freely call these “observer” methods (isDraw, isWinner, etc.): they only observe values, but they don’t change anything. Having methods like this means I don’t have to worry about “breaking” an object. A common beginner style error is to have a method that both answers a question about an object and changes its state (Imagine a method that, say, both makes a move and returns the current winner, if any. How do you then check winner without making a move, too? You can’t, unless you add another method. But then there are two methods that check winner, which means you need to keep them in sync, which means it’s easier to get later things wrong…).
Now we can also pretty easily return the game result, too:
public String getResult() {
if (isWinner(Space.X)) {
return "Player X wins!";
}
else if (isWinner(Space.O)) {
return "Player O wins!";
}
else if (isDraw()) {
return "It's a draw.";
}
else {
return "Game ain't over yet.";
}
}
It appears to work (demo in console). One possible test might be:
@Test
public void testDiagonalXWinner() {
TicTacToeBoard board = new TicTacToeBoard();
board.move(0);
board.move(1);
board.move(4);
board.move(3);
board.move(8);
assertEquals("Player X wins!", board.getResult());
}
What about renaming Space to Player, since that’s kinda a better name? Eclipse lets you “refactor” code (what “refactoring” means is kinda complicated, but…). One simple refactoring is to rename a variable. You could just find-and-replace, but Eclipse is smart enough to change only the variable you “mean” (for example, if you rename x to count in a method, it won’t change any variable named x in other methods). Right click on the variable or type definition or declaration, then choose “Refector -> Rename…” to do this task.
OK, enough tic-tac-toe. There’s more you could do (like make sure moves are in the right range, and not over an existing player’s move) but I’m sure you could figure it out (and test it!) yourself.
Eclipse and testing note!
There’s one last thing to tell you. Tests interact poorly with infinite loops. So at the top of most test files in this course’s assignments, you’ll see something like this:
@Rule
public Timeout globalTimeout = Timeout.seconds(10); // 10 seconds
This tells JUnit that if a test takes more than 10 seconds, it should just fail. If you don’t do this and your code contains an infinite loop, the tests will “hang” on any test that calles that code. (Demo.) And your laptop will heat up and the fan will spin and you’ll drain your battery, etc.
So the timeout stops this. But it also stops the test if you’re running it in the debugger. If you plan to use the debugger, you need to disable the timeout. Do this by commenting out both lines (the @Rule and the public Timeout... lines), and the debugger will no longer exit after 10 seconds – but if you have an infinite loop, tests will hang. (Gradescope takes 10 minutes to time out.)
Methods
In Java, methods are always attached to a class. A method consists of a declaration and a body, which is just a sequence of statements. Let’s look at a declaration more closely:
public static void main(String[] args) {
...
}
WTF is going on here!?!?! is usually the reaction we get in 121 when people first start learning Java. But now, you probably know enough to understand most of it. Let’s tackle it inside-out.
String[] args is the parameter to this method. One or more parameters are passed in, and they look like (and in many respects behave as) variable declarations. The difference is that their values are provided by the calling method (or in the very special case of main, by the JVM). Here, main gets an array of Strings, which are exactly what is passed on the command line to the java interpreter, e.g.,
public class PrintArgs {
public static void main(String[] args) {
int i = 0;
for (String a : args) {
System.out.println(i + ": " + a);
i += 1;
}
}
}
> javac PrintArgs.java
> java PrintArgs Hello Marc!
0: Hello
1: Marc!
Next is the name of the method, which is by convention “camelCased,” starting with a lowercase letter. Next is the method’s return type, or void if it does not return anything.
Important note: methods that return void typically do something, like print a value, or delete an item from a list, or the like. They affect state, or are stateful. Sometimes but not always, methods that return a value don’t do something (they are more like mathematical functions). The only way to be sure is to read the documentation (or the method code itself)! But a method’s public API should describe what it does.
Next comes one or more method modifiers: either abstract or one or more of static, final, and synchronized. static methods are associated with a class, but not a particular instance of that class (in other words, not with an object). We’ll talk more about the other modifiers later as they come up.
Finally there is at most one of public, protected, or private, which are member access modifiers. Which objects can invoke this method is determined by this modifier. public and private are probably familiar to you (any object and only objects of this class, respectively). protected and no modifier (“default access” or “package access”) have special meanings we’ll skip for now.