Java Reference
In-Depth Information
Now that we're through all the methods, we should look at the fields in the MineSweeper class. The
fields are the variables at the top of the class. Rather than make you flip all the pages between here and
there, Listing 7-11 shows the field definitions.
Listing 7-11. MineSweeper's fields
int columns = 8;
int rows = 8;
int numberOfMines = 10;
JFrame frame = new JFrame("MineSweeper");
JPanel minePanel = new JPanel();
JLabel minesRemainingLabel = new JLabel("Remaining:");
JLabel minesFoundLabel = new JLabel("Found: 0");
JButton[][] mineButtons;
Dimension buttonSize = new Dimension(20, 20);
MineField mineField;
MineSweeperMouseListener mouseListener;
MineSweeperActionListener actionListener;
MineSweeperHelper helper;
The rest of the
MineSweeper
class and the other classes that comprise the program use these values.
The three int values at the top control the size of the game and the number of mines. They have default
values (the values of the small size of the game) so that the game can load a version of the game when
the player starts the MineSweeper application. The
JFrame
,
JPanel
,
JLabel
,
JButton
, and
Dimension
objects help us define the user interface. The last four give us a way to refer to the other classes that we
use to make the program work.
To sum up our trip through MineSweeper class, we can make a few general observations about the
whole class. The most interesting thing about this class is programmatically creating a lot of buttons and
then figuring out which one the user selected. Another interesting thing is the ability to replace the
existing minefield and all its buttons with a new minefield and buttons when the user wants a new game
(because of winning or losing or choosing to abandon the current game). The
validate
methods on the
minePanel
and
frame
objects make that possible. After the existing buttons have been removed and new
buttons added, the
validate
methods tells the program to redraw the minefield panel and all its buttons.
If your own applications need to know which mouse button the user pressed, use the
MouseEvent.getButton
method, as we did here. In this case, we check only for the left button and treat
anything else as a right click (even though it could be some other button, such as the middle button).
Now let's move to the problems. This version of Minesweeper is an example, so it's far from perfect.
For one thing, rather than figure out which other buttons should be revealed when an empty spot is
clicked, the codecycles through the all the mines. I did that because the
MineField
class already has a
cascade
method for figuring out which neighboring locations would clear because of click. Also, I made
no attempt to optimize performance (though it runs as well as the Windows Minesweeper game on my
Windows laptop). Also, as you can see, I didn't bother to solve the problem of making the first click never
hit a mine. If you want to tackle that problem, by the way, populate the mine field after the user clicks
the first mine button (that's called late loading). Finally, I'm no artist, so the icons I created aren't much
to look at. They're ours, though, so we don't have to worry about copyrights to use them. Feel free to
create or find your own.
I separate the
MineField
and
Mine
classes from the user interface because I might want to use those
classes as the underpinnings of a Minesweeper game that does not use Swing. In particular, I might write
an Android version of Minesweeper, just for fun (it certainly wouldn't be a money maker, because many
