21. Machine Problem Comments

Association of Place and Schedule

The assignment involves two distinct but closely related problems:

• Kinds of places, roles of people, and associated schedules.
  A distinct schedule may be associated with each particular pair of place kind and role.
• Specific places, specific people, and associated schedules.
  A distinct schedule may be associated with each particular pair of place and person.

The question is, how do you represent this inside the computer? A schedule is, for now, a pair of floating point numbers, but we advertised at the start that schedules could have other attributes such as likelihood that a person will follow that schedule on any particular day. Representing a schedule inside the computer is therefore naturally done using a class:

class Schedule {
    float startTime;
    float endTime;
}

It's not unreasonable to add a toString method to print out a schedule and a constructor that reads the floating point numbers of a schedule by scanning an input stream. Adding these gives this:

class Schedule {
    float startTime;
    float endTime;
    // other fields that might show up, MWF, TuTh, etc
    Schedule( MyScanner in ) {
	// scan the pieces of a schedule up to and including the end paren
    }
    String toString() {
	return "(" + startTime + "-" + endTime + ")";
    }
}

But how do you associate a schedule with a pairing of people and places, or with a pairing of roles and kinds of places?

Looking over submissions of MP5, I saw some bizarre solutions, many of which cannot work correctly in the general case.

Reject solution 1: Parallel arrays can be used. Consider declaring these three arrays, or array lists, or similar:

Person pers[];
Place plac[];
Schedule sche[];

With these arrays, we can say that, for some value of i, the person pers[i] has the schedule sche[i] for the place plac[i]. This is indeed the way that a FORTRAN programmer in the 1960s would have solved the problem, because FORTRAN, back then, had no class or record structures. For anyone programming in a language developed after 1965, however, this kind of solution is inexcusable. We have stronger tools now.

Reject solution 2: Search the Java library, and you will find some cool ways to associate objects with other objects. Perhaps the most interesting is the HashMap. Hash maps really do interesting things. They can be used to connect the textual name of a thing to the object representing that thing. I avoided doing that in my solutions to the machine problem because I wanted to discourage people from thinking about hash maps to solve other problems. Hash maps do not, however, solve our problem.

Numerous students tried to do so, for example, creating hash maps from connecting place types and their schedules. The problem is, place types do not have schedules. Schedules are associated with pairings of people and places.

A road to a solution: Ultimately, we are being asked to output a list of person objects, where each person has a role and a list of associated places, each with a schedule. This immediately suggests the following classes:

class Person {
    Role myRole;
    LinkedList<PlaceSchedule> myPlaces;
}
Class PlaceSchedule {
    Place myPlace;
    Schedule mySchedule;
}

Similarly, the input file contains a list of roles, where each role has an associated list of kinds of places and their associated schedule. The data structure suggested by this parallels the above:

class Role {
    String name;
    LinkedList<PlaceKindSchedule> myPlaces;
}
Class PlaceKindSchedule {
    PlaceKind myPlace;
    Schedule mySchedule;
}

Don't imagine that adding lots of little support classes like PlaceKindSchedule and PlaceSchedule is a bad idea. It's a good thing to limit the visibility of these classes to the places where they are needed, and you can do that by declaring them as inner classes. In my solution, I was able to do this with private inner classes because each of these little auxiliary classes was used in only one class.

These auxilary classes do not need complicated flocks of methods. In my solution, I did include constructors simply because that allowed more readable use of these classes. I found no need for other methods.

Then, as each person object is created, you need to communicate to that new person the kinds of places they will visit and the schedules for those places. This involves following the data path from the role/place-kind data structure to the person/place data structure and making sure that the schedules are preserved.