Objects As Attributes

When we first discussed the attributes and methods associated with the Student class, we stated that some of the attributes could be represented by predefined types provided by the C# language, whereas the types of a few others (advisor, courseLoad, and transcript) were left undefined. Let's now put what we've learned about user-defined types to good use.

Rather than declaring the Student class's advisor attribute as simply a string representing the advisor's name, we'll declare it to be of user-defined type—namely, type Professor, another class that we've invented (see Table 3-2).

Table 3-2: Student Class Attributes, Revisited

Attribute	Type
name	string
studentID	string
birthdate	DateTime
address	string
major	string
gpa	double
advisor	Professor
courseLoad	???
transcript	???

By having declared the advisor attribute to be of type Professor—i.e., by making the advisor attribute a reference variable—we've just enabled a Student object to maintain a handle on the actual Professor object that is advising the student. We'll still leave the courseLoad and transcript types unspecified for the time being; we'll see how to handle these a bit later.

The Professor class, in turn, might be defined to have attributes as listed in Table 3-3.

Table 3-3: Student Class Attributes

Attribute	Type
name	string
employeeID	string
birthdate	DateTime
address	string
worksFor	string (or Department)
studentAdvisee	Student
teachingAssignments	???

Again, by having declared the studentAdvisee attribute of Professor to be of type Student—i.e., by making the studentAdvisee attribute a reference variable— we've just given a Professor object a way to hold onto/refer to the actual Student object that the professor is advising. We'll leave the type of teachingAssignments undefined for the time being.

The methods of the Professor class might be as follows:

• TransferToDepartment

• AdviseStudent

• AgreeToTeachCourse

• AssignGrades

A few noteworthy points about the Professor class:

• It's likely that a professor will be advising several students simultaneously, so having an attribute like studentAdvisee that can only reference a single Student object is not terribly useful. We'll discuss techniques for handling this in Chapter 6, when we talk about collections, which we'll also see as being useful for defining the teachingAssignments attribute of Professor and the courseLoad and transcript attributes of Student.

• The worksFor attribute represents the department to which a professor is assigned. We can choose to represent this as either a simple string representing the department name—for example, "MATH"—or as a reference variable that maintains a handle on a Department object—specifically, the Department object representing the "real-world" Math Department. Of course, to do so would require us to define the attributes and methods for a new class called Department. As we'll see in Part Two of this book, the decision of whether or not we need to invent a new user-defined type/class to represent a particular real-world concept/abstraction isn't always clear-cut.