3.8. Association
Whenever we create a class, such as Student or Professor, in which one or more of the fields are themselves references to other objects, we are employing an OO technique known as association. The number of levels to which objects can be conceptually bundled inside one another is endless, so association enables us to model very sophisticated real-world concepts. As it turns out, most "interesting" classes employ association.
With association, it may seem as if we're nesting objects one inside the other, as depicted in Figure 3-8.
Figure 3.8. Conceptual object "nesting"
Actual object nesting (that is, declaring one class inside of another) is possible in C# and does indeed sometimes make sense—namely, if an object A doesn't need to have a life of its own from the standpoint of an OO application, and exists only for the purpose of serving enclosing object B.
Think of your brain, for example, as an object that exists only within the context of your body (another object).
As an example of object nesting relevant to the SRS, let's consider a grade book used to track student performance in a particular course. If we were to define a GradeBook class and then create GradeBook objects as fields—one per Course object—then it might be reasonable for each GradeBook object to exist wholly within the context of its associated Course object. No other objects would need to communicate with the GradeBook directly; if a Student object wanted to ask a Course object what grade the Student has earned, the Course object might internally consult its embedded GradeBook object and simply hand a letter grade back to the Student.
However, we often encounter the situation—as with the sample Student and Professor classes—in which an object A needs to refer to an object B, object B needs to refer back to A, and both objects need to be able to respond to requests independently of each other as made by the application as a whole. In such a case, object references come to the rescue! In reality, we are not storing whole objects as fields inside of other objects; instead we are storing references to objects. When a field of an object A is defined in terms of an object reference B, the two objects exist separately in memory and simply have a convenient way of finding one another whenever it's necessary for them to interact. Think of yourself as an object and your cellular phone number as your reference. Other people—"objects"—can reach you to speak with you whenever they need to, even though they don't know where you're physically located, using your cell phone number.
Memory allocation using object references might look something like Figure 3-9 conceptually.
Figure 3.9. Objects exist separately in memory and maintain references to one another.
With this approach, each object is allocated in memory only once; the Student object knows how to find and communicate with its advisor (Professor) object whenever it needs to through its reference, and vice versa.
What do we gain by defining the Student's advisor field as a reference to a Professor object instead of merely storing the name of the advisor as a string field of the Student object?
For one thing, we can ask the Professor object its name whenever we need it (through a technique that we'll discuss in Chapter 4). Why is this important? To avoid data redundancy and the potential for loss of data integrity.
If the Professor object's name changes for some reason, the name will be stored only in one place: encapsulated as a field within the Professor object that "owns" the name, which is precisely where it belongs.
If we instead were to redundantly store the name of the Professor both as a string field of the Professor object and as a string field of the Student object, we'd have to remember to update the name in two places any time the name changed (or three, or four, or however many places this Professor's name is referenced as an advisor of countless Students). If we were to forget to do so, then the name of the Professor would be "out of synch" from one instance to another.
Just as importantly, by maintaining a reference to the Professor object via the advisor field of Student, the Student object can also request other services of this Professor object via whatever methods are defined for the Professor class. A Student object can, for example, ask its advisor (Professor) object where the office of the Professor is located, or what classes the Professor is teaching so that the Student can sign up for one of them.
Another advantage of using object references from an implementation standpoint is that they also reduce memory overhead. Storing a reference to (aka memory address of) an object requires only 4 bytes (on 32-bit machines) or 8 bytes (on 64-bit machines) of memory, instead of however many bytes of storage the referenced object as a whole occupies in memory. If we were to have to make a copy of an entire object every place we needed to refer to it in our application, we could quickly exhaust the total memory available to our application.