Lab 9: Classes, interfaces, and encapsulation

This project gives you practice writing classes that implement provided interfaces.

Clone the repository for this week's lab:

hg clone /cslab/class/csci235/lab9

Read the entire lab before you start coding. You need to have the big picture in mind. There are also some tips at the end about how you might break up the work into testable phases.

1. Introduction

Mathemematician John Conway invented the Game of Life as an exploration of a model of computation known as cellular automata. The rules are very simple, but the patterns produced can be entertaining. In today's lab you will implement the core of the game, working with a GUI that I have provided.

The world is a rectangular grid, and each cell (location) in the grid is either alive or dead. At every turn, each cell computes whether it will be alive or dead in the following turn, based on these rules:

A dead cell becomes alive if it has exactly three live neighbors.
A live cell remains alive if it has exactly two or three live neighbors; it dies if it has too few or too many live neighbors.

Note that the computation is local, occurring in each cell at the same time, depending solely on its own state and the state of its eight immediate neighbors.

2. The structure of the simulation

You have been provided with two interfaces, Grid and Cell, that define the methods for those two components of the simulation. Your job is to write classes LifeGrid and LifeCell that implement these interfaces.

The additional information that you need is that the constructor for LifeGrid takes two integer parameters, specifying the number of rows and columns, respectively, in the grid to be created. That constructor needs to create the grid and populate it with initially-dead instances of LifeCell. After it has created all of the cells, it then needs to iterate over the cells to tell each of them about all of its neighbor cells (calling addNeighbor()).

Note that a way to get started on each of LifeCell.java and LifeGrid.java would be to copy the corresponding interface file. To copy one of them and inform Mercurial about it, you can use a command like

hg copy Grid.java LifeGrid.java

If you create the file in some other way, you'll need to tell Mercurial to keep track of it with

hg add LifeGrid.java

Don't forget to commit your work to Mercurial at reasonable points.

3. Running the simulation

You can run the simulator with the command

java -cp .:life.jar ConwayLife

You'll see a picture of the grid; dead cells are black, live cells are green. If you click on a cell, its state will be toggled (calling the toggle() method you wrote). If you clock on the Step button, it will call your grid's plan() method and then its act() method before redisplaying the world.

To help you out a bit, the method that displays the grid uses two extra colors: index-out-of-bounds exceptions show up in yellow, and null pointer exceptions show up in red.

If you add two integers to the command line, you can specify the number of rows and columns for the world you create.

4. Working in stages

There is quite a bit to do here; it will be important to figure out how to do it in stages so that you can test pieces as you proceed. You can do that by providing dummy versions of methods methods at first, then replacing them as you get pieces working. Here are some observations that may help.

You can start by making a really stupid cell class. It will need a constructor, and it must return something from isAlive().
Your first version of the grid can simply create a suitable place to store it and populate it with your cells. All you need to make the program runnable is for the constructor and cellAt() to work; you don't need to worry about telling each cell about its neighbors yet.
Next, you might try giving each cell a current state; then implement the toggle() and die() methods.
Think about how to make a cell keep track of its neighbors (addNeighbor() and how it will use that information to plan its next turn. Finish the cell class by getting the plan() and act() methods done.
Important: planning should not change whether the cell is alive or dead; the change actually happens in act(). This split is necessary so that all of the cells make their decision based on the old state, and all change together.
What methods are still missing?

5. Turn in

Turn in the source files you modified (LifeCell.java and LifeGrid.java) as lab9.

Don't forget to copy the code to your own account.

Cary Gray (with code from Thomas VanDrunen)

Last modified: Fri Oct 21 11:05:23 CDT 2011