Back in Chapter 3, we defined the state of an object as the collective set of all of the object's attribute values at a given point in time; this includes
The values of all of the "simple" attributes for that object—in other words, attributes that don't represent other domain objects
The values of all of the reference variable attributes representing links to other domain objects
In Table 11-1, we've repeated the list of the Student class attributes from Chapter 6, adding a column to indicate which category each attribute falls into.
Attribute Name |
Data Type |
Represents Link(s) to an SRS Domain Object? |
---|---|---|
name |
string |
No |
studentID |
string |
No |
birthdate |
DateTime |
No |
address |
string |
No |
major |
string |
No |
gpa |
double |
No |
advisor |
Professor |
Yes |
courseLoad |
Collection of Course objects |
Yes |
transcript |
Collection of TranscriptEntry objects, or Transcript |
Yes |
In Chapter 10, we learned about UML object diagrams as a way of portraying a "snapshot" of the links between specific individual objects. Let's use an object diagram to reflect the state of a few hypothetical objects within the SRS domain.
In Figure 11-1, we see that Dr. Smith (a Professor) works for the Math Department, Dr. Green (another Professor) works for the Science Department, and that Bill and Mary, both Students, are majoring in Math and Science, respectively.
Bill is dissatisfied with his choice of majors, and calls Dr. Green, a professor whom he admires, to make an appointment. Bill wants to discuss the possibility of transferring to the Science Department. After meeting with Dr. Green and discussing his situation, Bill indeed decides to switch majors. We've informally reflected these object interactions using arrows on the object diagram in Figure 11-2; as this chapter progresses, you'll learn the "official" way to portray object interactions in UML notation.
When the dust settles from all of this activity, we see that the resultant state of the system has changed, as reflected in the revised object diagram "snapshot" in Figure 11-3. In particular
Bill's state has changed, because his link to the Math Department object has been replaced with a link to the Science Department object.
The Math Department object's state has changed, because it no longer has a link to Bill.
The Science Department's state has changed, because it now has an additional link (to Bill) that wasn't previously there.
Note, however, that although Dr. Green collaborated with Bill in helping him to make his decision to switch majors, the state of the "Dr. Green" (Professor) object has not changed as a result of the collaboration.
Objects' dynamic activities can result in changes to the static structure of a system—that is, the states of all of its objects taken collectively.
However, such activities needn't affect the state of all objects involved in a collaboration.
We saw in Chapter 4 that object collaborations are triggered by events. By way of review, an event is an external stimulus to an object, signaled to the object in the form of a message (method call). An event can be
User initiated (for example, the result of clicking a "button" on a GUI)
Initiated by another computer system (such as the arrival of information being transferred from the Student Billing System to the Student Registration System)
Initiated by another object within the same system (a Course object requesting some service of a Transcript object, for example)
When an object receives notification of an event via a message, it may react in one or more of the following ways:
An object may change its state.
An object may direct an event (message) toward another object.
An object may return a value.
An object may react with the external boundaries of its system.
An object may seemingly ignore an event.
Let's discuss these five types of reaction in detail, one-by-one.
An object may change its state (the values of its "simple" attributes and/or links to other objects), as in the case of a Professor object receiving a message to take on a new Student advisee, illustrated by the following code snippet:
Professor p = new Professor(); Student s = new Student(); // details omitted p.AddAdvisee(s);
Let's look at the code for the Professor class's AddAdvisee method to see how the Professor will respond to this message. We see that the Professor object is inserting the reference to Student object s that it is being handed as an argument into a Collection of Student object references called advisees:
public class Professor { // Attributes. // (pseudocode) Collection advisees; // Holds Student object references. // Other details omitted. public void AddAdvisee(Student s) { // Insert s into the advisees collection. // (pseudocode) advisees.Insert(s); } }
In so doing, Professor object p will have formed a new link of type advises with Student object s (see Figure 11-4). Typical "set" methods fall into this category of event response.
An object may direct an event (message) toward another object (including, perhaps, the sender of the original message), as in the case of a Section object receiving a message to register a Student, illustrated by the following code snippet:
Section x = new Section(); Student s = new Student(); // details omitted x.Register(s);
If we next look at the method code for the Section class's Register method to see how it will respond to this message, we see that the Section object in turn sends a message to the Student to be enrolled, to verify that the Student has completed a necessary prerequisite course:
public class Section { // details omitted bool Register(Student s) { // Verify that the student has completed a necessary // prerequisite course. (We are delegating part // of the work to another object, Student s.) // (pseudocode) bool completed = s.SuccessfullyCompleted(some prerequisite); if (completed) { register the student and return a value of true; } else { return a value of false to signal that the registration request has been rejected; } } }
This happens to be an example of delegation, which we discussed in Chapter 4: namely, another object (a Student, in this case) helping to fulfill a service request originally made of the Section object.
An object may return a value; the returned value may be one of the following:
The value of one of the object's private attributes
Some computed value (that is, a "pseudoattribute," as we discussed in Chapter 4)
A value that was obtained from some other object through delegation
A status code (as in true/false responses, signaling success or failure of Boolean methods)
Typical "get" methods fall into this category of event response.
An object may react with the external boundaries of a system: that is, it may display some information on a GUI, or cause information to be printed to a printer. As you'll learn in Chapters 15 and 16, however, what appears to be an external system boundary is often implemented in C# as yet another object.
Finally, an object may seemingly ignore an event, as would be the case if a Professor object received the message to add an advisee, but determined that the Student whom it was being asked to take on as an advisee was already an advisee:
Student s = new Student(); Professor p = new Professor(); // details omitted // Professor p will seemingly "ignore" this next message. p.AddAdvisee(s);
Let's look at a slightly different version of the AddAdvisee method than what we saw previously:
public class Professor { // (pseudocode) Collection advisees; // Holds Student object references. // details omitted public void AddAdvisee(Student s) { // ONLY insert s into the 'advisees' collection IF IT // ISN'T ALREADY IN THERE. // (pseudocode) if (s is already in collection) return; // do nothing else advisees.Insert(s); } }
Actually, to say that the Professor object is doing nothing is an oversimplification: at a minimum, the object is executing the appropriate method code, which is performing some internal state checks ("Is this student already one of my advisees?"). It's just that, when the dust settles, the Professor object has neither changed state nor fired off any messages to other objects, so it appears as if nothing has happened.