Message Chaining

In object-oriented programming languages like C#, it's quite commonplace to form complex expressions by concatenating one method call onto another via dot notation, a mechanism known as message chaining. Here's one hypothetical example:

Student s = new Student();
s.Name = "Fred";

Professor p = new Professor();
p.Name = "John";

Course c = new Course();
c.Name = "Math";


s.setFacultyAdvisor(p);
p.setCourseTaught(c);

Course c2 = new Course();
// A message "chain".
c2.Name = "Beginning " + (s.GetFacultyAdvisor().GetCourseTaught().Name);

As we saw in Chapter 1, we evaluate expressions from innermost to outermost parentheses, left to right, so let's evaluate the expression in the last line of this snippet:

1. Looking for the deepest level of nested parentheses, we see that part of the expression is two sets of parentheses deep, so we evaluate the left-most deepest subexpression first:

           s.GetFacultyAdvisor()
   

   which returns a reference to Professor p.

2. Next, we apply the GetCourseTaught() method to this Professor:

                 p.GetCourseTaught()
   

   which returns a reference to Course c.

3. Next, we access the Name property of this Course:

                 c.Name
   

   which returns the string value "Math".

4. We've now completed evaluating the expression enclosed within the innermost set of parentheses, effectively giving us the equivalent expression

                 c2.Name = "Beginning " + "Math";
   

So, we see in the final analysis that the outcome of the complex expression is to assign the name "Beginning Math" to Course object c2.

We'll see many such method chains in the SRS code.

Method Hiding

In Chapter 5, we learned that a derived class can override a method that has been declared as virtual in a base class: the derived class declares a new version of the base class method with the same signature, and includes the override keyword in the method declaration.

There is also a second way to replace the logic of a base class method, even one that hasn't been declared virtual in the base class, via a technique known as method hiding.

To "hide" a base class method, the derived class must define a method with the same signature using the new keyword in the method declaration in lieu of the override keyword. Here is a simple example in which the derived Student class hides the PrintDescription method first declared by the Person base class:

public class Person
{
  // details omitted

  // Note: no virtual keyword -- no provision for overriding was made
  // by the designers of the Person class.
  public void PrintDescription() {
    // details omitted
  }
}

public class Student : Person
{
  // The Student class HIDES the PrintDescription()
  // method from the Person class via the use of the
  // new keyword.
  public new void PrintDescription() {
    // details omitted
  }
}

Any base class method—whether virtual or not—can be hidden; thus, we have a work-around (of sorts) if we find ourselves in a position of wanting to modify the behavior of a method derived from a base class that wasn't "prepped" for overriding by the original designer of the base class via the inclusion of the virtual keyword in the base class's method signature. Note, however, that hiding a nonvirtual base class method differs from truly overriding a virtual base class method in one very significant way, having to do with the notion of polymorphism that we discussed in Chapter 7. Let's explore this issue.

// Iterating through an ArrayList of Students.
for (int i = 0; i < students.size(); i++) {
  Student s = (Student) students[i];

  // This next line of code is said to be polymorphic:
  // If s refers to a GraduateStudent at run time, the GraduateStudent version
  // of the ChooseMajor method will be executed; and, if s refers to an
  // UndergraduateStudent at run time, the UndergraduateStudent version of
  // ChooseMajor will be executed.
  s.ChooseMajor();
}

GraduateStudent g = new GraduateStudent();
g.ChooseMajor(); // GraduateStudent version of this method will execute

UndergraduateStudent s = new UndergraduateStudent();
s.ChooseMajor(); // UndergraduateStudent version of this method will execute

// Iterating through an ArrayList of Students.
for (int i = 0; i < students.size(); i++) {
  Student s = (Student) students[i];

  // This next line of code is NOT polymorphic:
  // Regardless of whether s refers to a GraduateStudent at run time or to
  // an Undergraduate student, the Student version of the ChooseMajor method
  // will be executed.
  s.ChooseMajor();
}

Overriding and Abstract Classes, Revisited

We learned in Chapter 7 that a class derived from an abstract class can be made concrete by providing nonabstract implementations of all of the abstract methods declared by the abstract base class. As it turns out, it's also possible to go the other direction as well: that is, a derived class can override a nonabstract method declared in a base class with an abstract method. Let's look at an example using predefined C# classes.

We know that every C# class implicitly derives from the Object class of the System namespace. One of the methods declared by the Object class is ToString, a nonabstract, virtual method that we discussed earlier in this chapter. It's perfectly acceptable to define a Person class that implicitly derives from Object (as all classes do), but which overrides the nonabstract ToString method it inherits from Object with an abstract version:

// Derives from Object implicitly.
public abstract class Person
{
  // We're overriding the nonabstract Object class's ToString method
  // with an ABSTRACT version.
  public abstract override string ToString();

  // Other Person class details omitted.
}

There are several things to note about the Person class:

• As discussed earlier in this chapter, derivation from the Object class is implicit, so we don't need the syntax : Object in the Person class declaration.

• Second, because the ToString method as defined in the Person class is abstract, the Person class itself is declared to be abstract.

• Finally, because the Person's ToString method is overriding the Object class's version of that method, the override keyword is used in the method declaration.

Why might we wish to override a nonabstract method with an abstract one? The answer is to force derived classes of Person to implement their own class-specific versions of the ToString method. That is, we don't want any of the future classes derived from Person to be "lazy" by simply inheriting the default behavior of the Object class's ToString method—we want to effectively "erase" the details of how this behavior is carried out. We'll in fact do this very thing when we create the Person class in Chapter 14 that will be used in conjunction with the SRS application. The Person class will declare an abstract ToString method that will be overridden by its derived classes.