The Actor 4 example begins where the Actor 3 example ends. As illustrated in the following UML class diagram, Actor 4 adds an overloaded inserter operator (operator<<) to each of the Actor 3 classes. The inserter serves the same purpose as the display function, and a "real" program would typically have one or the other but not both.
The Actor 4 UML class diagram. The Actor 4 example adds an overloaded inserter function, operator<<, to each class. The example demonstrates how programmers can chain inserter calls together by using the class relationships that bind the objects into a working program.
The example begins execution when the program creates an instance of the Star class in Actor 3, and the constructors "push" data from the Star constructor call to the other classes. When called, the Star inserter "pulls" the information from the other classes.
A Person "has an" Address by composition, and "has a" Date by aggregation
An Actor "is a" Person
A Star "is an" Actor
UML class diagrams are language agnostic (3), and so language-specific syntax, like pass and return by reference, is typically not included in the diagrams. Nevertheless, I have included the reference notation in the Actor example to clarify and reinforce some of the patterns that help us overload the inserter operator for any class. As you study the following examples, look for these elements. The inserter always:
is a friend function
is overloaded for a specific class
returns output stream by reference: ostream&
has an output stream reference as its first parameter, but programmers may choose the name: ostream& out
has a reference to the defining class as its second parameter, and programmers may choose an appropriate name: Date& me, etc.
ends by returning its first parameter: return out
All the inserters in the Actor example are very sort. So, each function is implemented inside its respective class. Place these function inside the Actor 3 class specifications to create the complete, final classes.
The part classes: Address and Date. Composition and aggregation are unidirectional or one-way whole/part relationships, and Address and Date are both parts. Therefore, neither class references any of the other classes in the class diagram. As a result, both inserter functions are very simple.
friend ostream& operator<<(ostream& out, Person& me)
{
out << me.name << " " << me.addr << endl; // composition and Person data
if (me.date != nullptr)
out << *me.date << endl; // aggregation
return out;
}
Person. Person is a complex class that plays two distinct roles. First, it is at the top of an inheritance hierarchy - the superclass to Actor and Star. But inheritance is unidirectional and a superclass does not "know" about its subclasses. Therefore, Actor and Star don't appear in the Person class's inserter function. But Person plays a second role as the whole to the Address and Date parts. Whole classes do "know" about their parts, and so the Person inserter must reflect that knowledge by calling the inserter functions in each of its parts in addition to printing any whole member data.
Aggregation and its pointers are the source of much of the whole class's complexity. Attempting to use a null pointer (e.g., as the left-hand operand to either the dot or arrow operator) causes a runtime error. So, we conditionally call the aggregated part only if the pointer is not null: if (me.date != nullptr). Next, no inserter function takes a pointer argument. So, we must dereference the pointer so the call matches the function's parameter list: *me.date.
Inheritance classes. Inheritance is also a one-way relationship, but from the subclass to the superclass. So, a Star "knows about" an Actor, and an Actor "knows about" a Person. Said another way, a Star "is an" Actor, and an Actor "is a"Person. We can use the "is a" concept to chain inserter function calls together so that the subclass inserter calls its superclass's inserter. The compiler determines which inserter function to call based on the second parameter, which is a reference to the defining class, and is therefore unique for every inserter function.
To do this, we cast the second argument into an instance of the superclass: (Actor &)me and (Person &)me. Not every cast involving a reference requires the ampersand, but it is needed sometimes and it never causes a problem to include it. The cast operation doesn't modify the argument but creates an expression that matches the the second argument of the superclass constructor. So, out << (Actor &)me matches the Actor inserter's parameter list and calls that function. Similarly, out << (Person &)me matches the Person inserter's parameter list, and calls that function.
