Faculty

Next, we'll create the Faculty class, which is used to populate a Hashtable with Professor objects by reading their pertinent information from two data files:

Faculty.dat, the primary file used as the basis for creating the Professors
TeachingAssignments.dat, a secondary file used for linking Professor objects to the Section objects that they are assigned to teach, and vice versa

Since the structure and behaviors of the Faculty class are so similar to those of CourseCatalog, we won't explain the Faculty class in detail, but will point out one interesting nuance regarding its ParseData2 method.

ParseData2 Method

The first part of the ParseData2 method of the Faculty class is similar to the logic that was used in the ParseData2 method of the CourseCatalog class: a line of text is read from a file and split into substrings using the Split method.

  // This next method is used when reading in the file that defines
  // teaching assignments.

  public override void ParseData2(string line) {
    // We're going to parse tab-delimited records into
    // two values, representing the professor's SSN
    // and the section number that he/she is going to teach.
    // Once again we'll make use of the Split() method to split
    // the line into substrings using a  tab as the delimiter.

    string[] strings = line.Split('\t');

    // Now assign the value of the substring to an appropriate
    // local string variable.

    string ssn = strings[0];

    // The full section number is a  concatenation of the
    // course no. and section no., separated by a  hyphen;
    // e.g., "ART101 - 1".

    string fullSectionNo = strings[1];

Just as we did in the ParseData2 method of CourseCatalog, we're linking together two objects here, and so we need to first verify that both objects do indeed exist, and obtain handles on them. But, unlike the ParseData2 method of CourseCatalog, where both objects were Courses, and hence both objects were stored in the Hashtable internal to the CourseCatalog class, here we have a situation where one of the objects (a Professor) is stored in our own internal professors Hashtable, but the other object (a Section) is stored in a collection elsewhere in our application: namely, in the scheduleOfClasses collection that we've defined as an attribute of the main SRS class. However, by declaring the latter collection to be a public static attribute of the SRS class, we have in essence made it globally visible/accessible to the entire application, which enables us to reference it as highlighted in the following code:

    // Look these two objects up in the appropriate collections.
    // Note that having made scheduleOfClasses a  public
    // static attribute of the SRS class helps!

    Professor p = FindProfessor(ssn);
    Section s = SRS.scheduleOfClasses.FindSection(fullSectionNo);
    if (p != null && s != null) {
      p.AgreeToTeach(s);
    }
  }

Adding a "Test Scaffold" Main Method

Just as we did for CourseCatalog, we also provide a test scaffold Main method for the Faculty class. We're a bit constrained with regard to testing the full functionality of Faculty in this manner, however: because the ParseData2 method expects to access the SRS.scheduleOfClasses collection object, and because we won't have instantiated that object through our test scaffold, we can't put the ParseData2 method through its paces without running the full-blown SRS application. Nonetheless, we'll go ahead and at least test our code for reading the primary file, Faculty.dat.

  // Test scaffold.
  static void Main() {
    Faculty f = new Faculty();
    f.InitializeObjects("Faculty.dat", true);

    // We cannot test the next feature, because the code
    // of ParseData2() expects the SRS.scheduleOfClasses
    // collection object to have been instantiated; but
    // it will NOT have been if we are running this test
    // scaffold instead; hence, we've commented out the next line.
    // f.InitializeObjects("TeachingAssignments.dat", false);

    f.Display();
  }