Composition

Whenever we create a class, such as Student or Professor, in which one or more of the attributes are themselves handles on other objects, we are employing an OO technique known as composition. The number of levels to which objects can be conceptually bundled inside one another is endless, and so composition enables us to model very sophisticated real-world concepts. As it turns out, most "interesting" classes employ composition.

With composition, it may seem as though we're nesting objects one inside the other, as depicted in Figure 3-8.

Figure 3-8: Conceptual object "nesting"

Actual object nesting (i.e., declaring one class inside of another) is possible in some OO programming languages, 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 only exists 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 attributes—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 wished 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, handles come to the rescue! In reality, we are not storing whole objects as attributes inside of other objects; rather, we are storing references to objects. When an attribute 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 handles might look something like Figure 3-9 conceptually.

Figure 3-9: Objects exist separately in memory and maintain handles on 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 handle/reference, and vice versa.

What do we gain by defining the Student's advisor attribute as a reference to a Professor object, instead of merely storing the name of the advisor as a string attribute 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 only be stored in one place: encapsulated as an attribute within the Professor object that "owns" the name, which is precisely where it belongs.
If we instead were to redundantly store the Professor's name both as a string attribute of the Professor object and as a string attribute 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 handle on the Professor object via the advisor attribute 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 may, for example, ask its advisor (Professor) object where the Professor's office 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 handles from an implementation stand-point is that they also reduce memory overhead. Storing a reference to (aka memory address of) an object only requires 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.