overall design of a java application
The overall design of a java application, which contains several classes, is a subject which I do not control very much.
I know how to declare classes and to write methods. I also know how to create objects of each class and further use its methods as a matter of communication between classes (the get/set business). What actually puzzles me is how to put these elements together in an efficient manner.
Consider the following example.
I created a package of 15 classes called Cites (in French Cités, Cities). The package is the electronic audio component of a composition for cello and soprano on text of Appolinaire. The classes can be divided into two different groups of 3 and 12 classes each. The first three I would call: midiPort, midiEdit and midiControler. The second group, cites1 to 12, is the 12 sound blocks. The best way to understand all this is to see the group (1-12) as tracks of audio CD and to understand the first group of three classes as the actual CD-player (the 12 soundblocks run on rand generators and sound each time slightly different).
The first group consists of a series of stand-alone classes that can and should be re-used in an oop manner:
1) midiPort sits at the bottom part and sends the midi-bytes out (midi-out) to a small synthesizer module of Yamaha called FBO-1 (20 years old!). midiPort also reads out (midi-out) the code of a midi pedal, which is used to control the tracks of the 12 soundblocks (actual in a top down sequence from 1 to 12). (In fact the pedal triggers also several other sound events but lets not go into details here).
2) midiEdit is a full-fledged Frequency Modulation editor for the FBO-1 and is used in real-time by each soundblock.
3) midiController, harbors a swing clock, which, with its 10 mili seconds pulse, forms the time-line of all musical events of the soundblocks. It also sets some GUI stuff so the user (cello player) could control thinks (eg setting the midi device, testing it, and 12 radio buttons for each soundblock during rehearsals).
The midiPort is the lowest level of this application; it is used by midiEdit, for midi-out, and midiController, for midi-in (midi pedal only). The 12 sounblock each use both classes’ midiEdit and midiController! So one can say that there are three levels.
Until now, testing the components, I simply had all 12 soundblocks in one class declared as public void methods. In that class I created object of 2) and 3) and called all 12 methods in its constructor (the GUI part is not written yet). I controlled the events by listening and console output….. it worked for testing.
Of course designing it all, with GUI interaction included, would create a whole different design. Where to start? From the bottom (midiPort), or from the top (where live the cites1 to 12 classes). Or should I yet design another, Main, class where finally --the cork, of the bottleneck where one finds the famous “public static void main(String args)” method, which, eventual triggers the whole thing.
Should one always start with the GUI-component. (In smaller applications I constructed all GUI stuff at the contructor of that single class, maybe a bad habbit?). I noticed, studying examples of hardwired, that one also may use methods to construct the GUI, which are triggered by the constructor of the class, which usually extends JPanel (as top container).