Midterm Tues., Apr. 2
Last time: finished Chap 8, to pg. 532
We’ll use the SysInventory system of project p2 to replace the Stock example at the end of Chap. 8
Next week: Chap 9, Sec 9.5 Interfaces, so skip Sec. 9.1-9.4 for now
Look at ITSytem again
ITSystem(int id, int roomNo, int problems)
void recordProblem() // increment problem count
public int getId()
public int getRoomNo()
public int getProblemCount()
// you add toString()
Example of use: create an ITSystem for with id 2, in room 103, with 1 recorded problem:
ITSystem sys = new ITSystem(2, 103, 1);
Print out “system 2 is in room 103” based on this new object:
System.out.println(“system “ + sys.getId() + “ is in room “+ sys.getRoom());
Crucial field of SysInventory: private ITSystem [] systems; // the systems we're tracking
An inventory object contains a whole array of ITSystems.
<picture of SysInventory object with array object hanging off it, and ITSystem objects hanging off of the array>
Run system to see how to load up the array
In this project, there are two object types, ITSystem and SysInventory. The idea of SysInventory is a place for the whole collection of systems, i.e., the system inventory for the department.
A SysInventory holds an array of ITSystems. The inventory has a name, and a Scanner to talk to a user and take commands. This is an interactive object, unlike the ITSystem, which never interacts directly with a user.
We looked at the various methods in SysInventory.
We considered how the code runs in the following case, after 2 systems have been set up.
Enter system inventory number, 0 to quit: 2
System 2 selected
Actions: exit, help, print, record-problem
Enter action: record-problem
The system now has 1 recorded problems
Enter action: exit
Then we drew a call graph, showing how main calls doCommands, then doCommands calls whichITSystem, and it calls promptInt, then returns to whichITSystems, and so on. In this crude version below, the lines should be down arrows, and there should be return arrows as well, showing return values in some cases.
doCommands, ßSysInventory public method, part of its API, called from main in SysInventoryMain.
/ \
whichITSystem processActionsForITSystem ßSysInventory helper methods
| | \
promptInt prompt system.recordProblem, a call into ITSystem code
Idea of a helper method. Here doCommands is called from main, and to do its work, calls whichITSystem and processActionsForITSystem, which call other methods. These methods that never get called from outside the class are called helper methods. Note that system.recordProblem is not a helper, because it involves a call between classes, in this case from SysInventory into ITSystem. On the other hand, promptInt and prompt are more helpers.
We’ve seen how private fields hide data away from other-class code. Similarly private methods are hidden in their classes, away from other-class code. When we mark a method private, it means we’re using it as a “helper” to the other methods in the class, so it isn’t expected to be called on its own. It’s not in the API. The API consists of the public methods and constructors.
SysInventory’s API is as usual the set of public methods and constructors:
SysInventory(String name)
void open(Scanner input) // set up the inventory, with help of input
void doCommands() // process commands: exit, help, print, record-problem, others to be added
That’s it—no getters here. To find out things, the user has to enter commands. Of course we could add a “getName()” method, but we don’t need it.
Example of coding with this system—add a field “hostname” and support lookup by it.—postponed to next time. That discussion will help with #4, where you add a feature to find the system to work on by room number. So concentrate on earlier problems before then, and the narrative of #5.
We went over p1 problems 2 and 3.