Test Scores App (see diagram)
The most important function of this class is to provide “public static void main” method since when Java sees a bunch of classes with multiple methods – it doesn't know where to start compared to using programs versus pure classes, where you just have to start the execution from the first line in the program. So they use the trick – Java seeks the method called “main” and starts execution there.
Since its role is to be an entry point to the system of interacting classes and initialize the beginning of the system's operations it has to have minimum to nothing operations. In our case it determines (a la MVC) the active part which in event-driven environments (see my previous post) determine the sequence of execution – which is the VIEW (Test Scores View in our case). It also (attention here!) instantiates the specific Model (Test Scores Model) and passes it (the whole class!!!) as a parameter to the View. AND THAT'S IT! This is a very typical way of designing MVC systems for popular business (and other) uses. Next time you design the system of yo own – remember this pattern and just rewrite it. Chances are that this model will be your first model in all those cases (including this week's task)
TestScoresModel class
Usually the Model includes the class(es) that are clearly separated from the interface. Think if you can easily change interface from console dialog with loops to a complex GUI Window WITHOUT changing the Model. If you can – than you already satisfied the necessary condition for a proper model design.
In our case the model describes operations that can be performed on the main conceptual system of our project – which is... yes, you are right, which is the array of Students (Student objects created from the same Student class) – see the diagram, which starts looking more an more useful.
In typical business systems they usually have at least one in-memory database-like data structure. The typical operations for your future development, again without much thinking, will include full VCR-style navigation (first, last, previous, next) as well as the complete set of database file management CRUD operations (Create a record, Remove, Update, Delete). Additional operations required by the customer should also be here like: getClassAverage, getHighScore, etc.
Therefore, in this class you have to instantiate an adequate memory structure (array of objects in our case). Then you will ALWAYS need (again without thinking in the future) to have a variable like indexSelectedStudent, which keeps the current position. The CURRENT POSITION is a very important concept in data processing since all navigation operations (next, previous, etc) are done with respect to the Current Position stored in such variable. Then moving to the next or previous is a matter of adding or subtracting 1 from the current position. Remember that position starts with one, but index always works from 0. So some adjustment might be necessary.
In case of data structures where you have to decide on the length of the array in advance – a special variable like studentCount will be very important for control of the really filled records not to show the blank array elements and to minimize all the loops done on arrays to the real count of records (like looping only through 10 REAL records in an array that can have 10000 elements).
When a new Student object arrives or is replaced it is just a matter of assigning the pointer to that student to the element of the students array like in:
students[studentCount] = s;
Student class
Since the main conceptual focus is usually on complex data structures with multiple more simple elements (like Students in students array) we will need a special class for each of these simple (relatively) primary structures (classes) to maintain independence from their life cycles, like adding more elements and methods to Students making them more complicated.
TestScoresView
This is the VIEW, which designs and declares the View elements (see the program). Notice abundance of fields for information communication, buttons, etc. It can fit all the multiple dialog windows that some of you preserved in the first game GUI design.
Notice the well-developed constructor that has to provide a working version of the interface window at the start of the program (since it is event-driven and nothing is executed without user's actions on the interface).
A traditional method (you can use it in many cases similar to this one) is in the use of one Structure filling all the visible elements of the WHOLE interface - this is displayInfo method using all visible fields. The idea is that AT ALLL TIMES users should see something (otherwise they get scared and think that they ruined something). Such collection of fields in one method will be constantly reused in the View since after controllers do their thing – the result will be always in calling this method to prepare the image for the main interface window.
Also notice that using Model makes View operations (your task for the week) trivial – just get info from the screen or from the button (using Controller) and pass it to the Model for Execution with delivering the result back to the same displayInfo method.
