Designing for Two
In our last tutorials, we were not concerned with design at all. Rather we were exploring a new design space (Swing) to find out what we could do with it. Armed with that knowledge we now embark on a complete design from scratch.
You have been asked to split your project into two pieces so that each partner has a piece of their own. This is generally a good way to work on a multi-person project anyway. But how to do it? In essence, like the old joke, you want to divide the world into two categories. Of course, there is an unlimited number of ways to draw a single dividing line but, given the kind of project you've got, one natural division is between graphical and non-graphical programming. This is particularly appealing in real projects because of the specialised nature of graphical programmingit allows team members to focus their expertise.
This particular parsing is sufficiently compelling that it is recognized as a standard pattern, the model-view pattern (also known as the document-view pattern). So this tutorial presents a skeletal design for Latrunculi breaking it into separate model and view parts.
To create two packages one of which is exclusively concerned with modelling the game, Latrunculi, the other which is exclusively concerned with presenting Latrunculi on a computer screen.
The Skeletal Design
Here is the class diagram for the skeletal design (the actual Rose file is also available). It conceives of two packages StandardView (the name admits of the possibility of other views in the future) and ModelPackage. LMainFrame is the top level frame built in the visual environment and is also, de facto, the top level in the graphics system. ConcreteModel is its counterpart in the modelling side.
Both of them implement carefully-designed interfaces through which they communicate to their counterpart. The interface for the model side is ModelGame which in turn is derived from two separate interfaces, one for callbacks and one for commands. ViewFrame is the interface for the view side. The concrete classes have a reference only to their counterpart's interface. Thus the interfaces define completely the communications between the two sides.
The main mechanism for changing the view is for the model to call its refresh method every time there is a change. The model is in charge of the game and how it is played and thus it knows when the view is out of date. The call is a simple one. The model does not push the changed information at the view. Instead it provides callbacks for every piece of information view might want to know. The various objects in the view package (once it is developed) will carry a reference to the model interface. When told to refresh they will call back to the model for whatever information they need. Callbacks, being simple queries, can't change the state of the model.
These can (and generally do) affect the state of the model. Controllers (e.g. keyboard, mouse) are handled on the view side, so commands are necessary handles for passing controller actions in to the model.
Provides a command interface for the view. In this case, refresh updates the main display; showRuling and hideRuling allow rulings to be put up and taken down in a yet to be decided manner (rulings will probably require some more stuff in the interfaces when they get worked out in detail); and confirmConfig allows the model (which knows about the state of the game) to ask the view system (which knows how to talk to users) to confirm a configuration request made while a game is under way.
This system is easy to maintain and upgrade. While it is far from complete, it should give you the flavour of how to design for two.