I currently have an program in Java that simulates railway movements. Essentially, trains arrive on platforms, pick up and drop off passengers, and then proceed, respecting signalling where possible. However, currently this only exists in the program’s state, and there is no actual graphical view of all of this happening.
It would be much more useful if one could see a diagram of the railway track and where trains were on it. To do this, everything now has to have (x, y) coordinates in respect of the JPanel so that they can be drawn. There are probably other useful fields and methods that would be useful in terms of depicting the current state.
I see two principal options:
-
Just throwing everything into the original classes. However, I don’t like this since it’s not a property of a train that it exists at (2, 3) on an arbitrary JPanel, that just happens to be a representation.
-
Creating a Visualizer class for every class that needs to be drawn, so there would be a TrainVisualizer class, a PlatformVisualizer class, etc., and all of these classes would inherit from a generic Visualizer class that would handle coordinates and such. The problem with this is that every time I create something, I basically have to create both the original thing (i.e. the Train), and the visualizer. This seems like the MVC pattern, but I’ve never quite understood it, and it does seem a bit unideal to have to have two classes for pretty much everything.
What would be the best way of adding this on to the existing program?
At design level you have a couple of options:
- Every now and then redraw the entire world
- Redraw the entire world when it has changed
- Every now and then check whether or not the world has changed. If so redraw the entire world.
- If something changes, redraw the affected parts of the world
- Every now and then check for changes and only redraw the affected parts of the world.
Every option has its positive and negative effects:
- Redrawing the entire world saves time spent on figuring out the affected areas.
- Redrawing parts of the world saves time spent on rendering
- Redrawing with every change will give fast feedback to the viewer
- Redrawing batched changes will accumulate changes in the same area and draw them in one go.
The way to select one of these options is to figure out (first a guess, later measuring) the size of the world, the number of changes, time spent on rendering, time needed for calculations, minimal required lag/frame rate.
It is not that hard to build them all the only thing that might have a huge impact is a notification per change/area as it will involve a lot of signaling between Model and View.
I’d go for full screen redraw every now and then and see if that is good enough because that is easiest to implement.
If it doesn’t suffice, make it smarter.
Full screen drawing could be implemented by a Visitor that visits the world structure (or a copy of it that represents a moment in time) and paints it.
For area painting you could do something similar. There is no need to put all the drawing code in the Model, that is the job of the View.