Java Reference
In-Depth Information
File: its/BlockPuzzle/BlockPuzzle.java
package its.BlockPuzzle;
1.
2.
3.
4.
class BlockPuzzle{
5.
6.
public static void main(String[] args){
7.
BlockPuzzleFrame g1f = new BlockPuzzleFrame(4,4);
8.
g1f.showIt();
9.
}
10.
}
14.5
Summary
The example in this chapter is to illustrate the design process of a graphical ap-
plication. The non-graphical part is specified, implemented and tested separately
from the graphical one. Both graphical and non-graphical classes supply the meth-
ods needed by the control part. For example BoardModel implements the move in
moveIt and BlockPuzzelPanel supplies a pixel-to-block-number transformation
in getBlockNoAtPixels .
The approach of separating data administration, graphics and user interaction
is the key to a rapid save and easily maintainable implementation. An often-heard
claim is that this slows down the program execution because, for example, the use
of get - and set -methods is slower than direct access to public variables. This is
almost always incorrect. One can achieve between 0 and 2 per cent speed-up for
most applications by using a badly structured unsave and hard-to-maintain imple-
mentation. The time to debug such an implementation is, however, considerably
larger.
In our block puzzle example we have been able to implement the model, view
and control parts one after the other. Though a conceptional separation of these
parts is always possible, a temporal separation is not. One will often have to develop
the three parts separately, but parallel.
The block puzzle example is kept very short. It lacks a number of important
tests, such as checking whether the numbers of rows and columns are positive
in the constructor of BoardModel . Also the determination of the block clicked by
method getBlockNoAtPixels is precise only to within a few pixels.
Exercises
14.1
Add a 'reset' button to the GUI. On pressing it the blocks are arranged in the
initial configuration.
Search WWH ::




Custom Search