Single Inheritance

In the case of class Rectangle, although it inherits from both Enclosed shape and Enclosed shape with at least one angle, its inheritance hierarchy is an example of single inheritance. Single inheritance is where each class has one and only one direct ancestor class. The relationship between class Rectangle and class Enclosed shape is indirect due to the intervening presence of class Enclosed shape with at least one angle in the inheritance path between them, but this still constitutes single inheritance due to the fact that all classes in the hierarchy have only one direct ancestor class.

Multiple Inheritance

In contrast, the inheritance hierarchy for class Student Employee is an example of multiple inheritance. Multiple inheritance occurs when a class has more than one direct ancestor class, as illustrated by class Student Employee having a direct ancestry path both to the Student class and to the Employee class.

Effect of Inheritance upon Member Visibility

Inheritance offers classes the use of a new level of visibility that can be assigned to its members, which is more restrictive than public visibility but not as restrictive as private visibility. This level of visibility is known as protected. Members marked protected are visible only to the class in which the members are defined and to any child classes inheriting directly or indirectly from the class. In order for a child class to have visibility to a member it inherits from its parent class, the member must be defined at least with protected visibility. Those members defined in a parent class with private visibility are inaccessible to child classes.⁵

As mentioned, it is commonplace for attributes of a class to have a level of visibility more restrictive than the behaviors of the class. This concept is also applicable to inheritance. A class might provide public getter and setter methods to external entities that have no visibility to the attributes of the class, an arrangement embodied by the phrase “public behaviors and private attributes.” Private attributes of a parent class are not visible to a child class. It is protected visibility that makes inherited attributes visible to the child class at the same time keeping them invisible to external entities. This continues to conform with the idea of attributes having a level of visibility more restrictive than the behaviors of a class, but to accommodate the effect of inheritance we need to expand the visibility phrase to become “public behaviors and private and protected attributes.”

Effect of Inheritance upon Constructor Methods

As explained previously, instance constructor methods are invoked automatically during the instantiation of an object and static constructor methods are invoked automatically upon the first encounter of a statement referencing the class. With inheritance, the constructor methods of each parent class in the ancestry path also participate. A class in the inheritance hierarchy that does not explicitly define an instance constructor method or a static constructor method implicitly will have these made available to it.

Figure 5-4 shows an example inheritance hierarchy with a maximum depth of five levels and containing classes exhibiting both single and multiple inheritance . At the lowest level we see three classes of dogs (beagle, chihuahua, and dachshund) all inheriting from class dog. Class dog, in turn, inherits both from class canine and from class domesticPet, and is the only class in this inheritance hierarchy to inherit from more than one other class. We will use this diagram to describe how the static and instance constructors of parent classes get invoked.

Figure 5-4. Inheritance hierarchy where class dog illustrates multiple inheritance

Effect of Inheritance upon Static Constructor Methods

As mentioned, a static constructor is used to initialize the static attributes of the class, does not have access to any of the instance members of its class and, because there is no specific statement that will cause a static constructor to be invoked, cannot include a method signature. Recall also that static constructors are invoked automatically by the runtime environment when a class is first accessed. Within a class inheritance hierarchy, the runtime environment insures that the static constructors of more specialized classes will be started only after all of the static constructors of more generalized classes in the hierarchy have finished.

To understand why it is necessary to delay static constructor execution until the static constructors of all superclasses have finished, let’s suppose that every one of the classes we see in the inheritance hierarchy diagram in Figure 5-4 includes static attributes that span the spectrum of visibility: public, protected, package, and private. For those static attributes with public and protected (and perhaps package) visibility, the static constructor of a subclass will also have access to these attributes during its processing. These attributes will need to be initialized by their own static constructor before the static constructor of the subclass can use them effectively. Accordingly, the static constructors of a class inheritance hierarchy are executed in order from most generalized class to most specialized class for whichever classes have not yet been accessed once already. So, when a class is accessed for the first time, the runtime system will identify the names of the classes participating in the inheritance hierarchy, make a list of them, sort the list from most generalized to most specialized, and then run through the list, starting with the most generalized class, executing the corresponding static constructor, if one exists and has not yet been executed.

For example, let’s say a program calls for the instantiation of a dachshund class, the class shown in the lower right of the inheritance hierarchy in Figure 5-4, and this is the first time any one of these classes has been accessed. The names of the classes participating in the inheritance hierarchy, from most general to most specific, are

• animal

• mammal

• canine

• domesticPet

• dog

• dachshund

The runtime environment will first execute the static constructor of the animal class. This is followed by executing the static constructor of the mammal class, which will now have available to it accurate initial values for the public and protected static attributes of the animal class. Then the static constructor of the canine class is executed, which will have available to it accurate initial values for the public and protected static attributes of both the animal and mammal classes. This process continues until finally the static constructor of the dachshund class is executed, which will have available to it accurate initial values for the public and protected static attributes of all the classes of its ancestry.

Notice that class domesticPet appears in the list between classes canine and dog, and represents a different branch in the inheritance structure from class dachshund. It is neither more general nor more specific than class canine, its predecessor entry in the list, since they do not share the same inheritance path. What is important here is that both the canine and the domesticPet classes precede the dog class in the list, because both are more generalized classes relative to class dog, and each of their respective static constructors must be executed prior to executing the static constructor of class dog.

For another example, let’s say a program first calls for the instantiation of an equine class, and this is the first time any one of these classes has been accessed. The names of the classes participating in the inheritance hierarchy in Figure 5-4, from most general to most specific, are

• animal

• mammal

• equine

The runtime environment will execute the static constructors of the animal class, mammal class, and equine class, in that order. Subsequent processing in the same program calls for the instantiation of a fox class. Now the names of the classes participating in the inheritance hierarchy, from most general to most specific, are

• animal

• mammal

• canine

• fox

The runtime environment will execute the static constructors of the canine class and fox class, in that order. The static constructors for the animal and mammal classes will not be executed since they were already executed during the creation of the equine instance.

Effect of Inheritance upon Instance Constructor Methods

Remember that instance constructors are executed automatically by the runtime environment when a new object is being created, and because new instances of objects are requested explicitly, an instance constructor can include a method signature. Accordingly, the programmer causes an instance constructor to be executed by creating a new object.

In the previous section, it was explained how the runtime environment insures that, within a class inheritance hierarchy, the static constructors of more specialized classes will be started only after all of the static constructors of more generalized classes in the hierarchy have finished. In contrast, instance constructors of more specialized classes are started prior to the start of instance constructors of more generalized classes. In some object-oriented environments, the first action of the instance constructor must be to invoke the instance constructors of its superclasses. In other object-oriented environments, an instance constructor may perform some processing prior to invoking the instance constructors of its superclasses. C++ and Java fall into the former category where an instance constructor first must invoke its superclass instance constructors. ABAP falls into the latter category where an instance constructor may delay invoking the instance constructors of its superclasses. Regardless of which of these approaches is in effect, the same fundamental concept applying to static attributes also applies to instance attributes; specifically, a superclass needs to be able to initialize the public and protected instance attributes before a subclass can use them effectively. Indeed, an instance constructor must invoke the instance constructors of its superclasses at some point so that this initialization can occur.

For those environments in which an instance constructor may perform some processing prior to invoking the instance constructors of its superclasses, the programmer has control over the point at which the instance constructors of the superclasses get invoked. Until that point, the instance constructor may not make reference to any instance attributes or invoke any instance methods; its access is restricted to static attributes and static methods, parameters defined by the signature of the instance constructor, and any local variables that may have been defined within the instance constructor method. It is only upon return from invoking the superclass instance constructors when all instance attributes and methods become available to a constructor method.

Now, let’s return to the famous sentence we saw in Chapter 2:

• The quick brown fox jumps over the lazy dog.

To review, we determined that this sentence implies two classes, a fox class and a dog class, and further, as shown in Table 5-3 (a copy of Table 2-1 from Chapter 2), that the dog class has an attribute for alacrity, and that the fox class has attributes for alacrity and color as well as a behavior for jump.

Table 5-4 includes the fox class and dog class, and all of their respective parent classes based on our example class inheritance hierarchy diagram shown in Figure 5-4. Here the attributes and behaviors shown for the fox and dog classes in the preceding chart have been assigned to the most appropriate inheritance level, where the attribute for color has been renamed to furColor. Some instance attributes and behaviors that might be associated with each class also have been included.

Further, suppose that we have decided to define an instance constructor for class animal that accommodates setting a value for its alacrity attribute, and we have decided to also define an instance constructor for class canine that accommodates setting a value for its furColor attribute, as shown in Table 5-5.

Table 5-6 shows the complete fox and dog classes with all of the attributes and behaviors inherited from other classes as illustrated in Table 5-5.

In Chapter 2, we provided the following lines of pseudocode to fulfill the intent of the original statement:

create object fox
fox.set_color("brown")
fox.set_alacrity("quick")

create object dog
dog.set_alacrity("lazy")

fox.jump(dog)

This, of course, was before we understood about constructors. Now that we are familiar with the concept of constructors, we can use the following abbreviated pseudocode and get the same result:

create object fox("brown","quick")

create object dog(" "    ,"lazy")

fox.jump(dog)

Here we no longer have the statements explicitly setting the color and alacrity attributes after the instances of fox and dog have been created, but include this information with the request to instantiate these objects. This technique requires that we define constructor methods for both the fox and dog classes, which will set the instance attributes accordingly.

Consider that with this inheritance hierarchy, these attributes – alacrity and furColor (formerly simply called color) – are contributed by two different classes in the hierarchy: classes fox and dog both inherit the attribute furColor from class canine, but they inherit the attribute alacrity from class animal. Furthermore, recall that it was decided to define two instance constructors: one for class animal to facilitate setting a value for its alacrity attribute, and another for class canine to facilitate setting a value for its furColor attribute.

When an object is instantiated, it becomes an aggregation of its own attributes and methods and all of the attributes and methods it inherits from all classes in its inheritance hierarchy. In addition, all the instance constructors defined for each contributing class are executed to perform whatever actions are defined in those respective instance constructor methods. Those classes with no explicit instance constructor will have an implicit instance constructor that facilitates calling the instance constructor at the next highest level in the hierarchy , thus insuring that instance constructors defined throughout the inheritance hierarchy are executed.

In the case of the fox class, for the statement

create object fox("brown","quick")

the parameter values “brown” and “quick” are passed to the instance constructor methods accordingly. The instance constructor method for class canine would use “brown” to set the value of the furColor attribute it contributes to the new instance of fox, and the instance constructor method for class animal would use “quick” to set the value of the alacrity attribute it contributes.

Similarly, in the case of the dog class, for the statement

create object dog(" "    ,"lazy")

the parameter values “ “ and “quick” also are passed to the instance constructor methods. The instance constructor method for class canine would use a blank to set the value of the furColor attribute it contributes to the new instance of dog, and the instance constructor method for class animal would use “lazy” to set the value of the alacrity attribute it contributes.

We should recognize in this case that there are no instance constructor methods defined for classes fox, dog, or mammal, even though the instance constructors of their respective parent classes are executed.

This example vastly oversimplifies the interaction of instance constructors during instance creation. Each object-oriented environment has its own protocol for facilitating, during object instantiation, the call to the constructor method for each successive class in the inheritance hierarchy. There needs to be a way to pass up through the inheritance hierarchy only those values that apply to parent classes along the same line of ancestry, so that the respective instance constructor methods may perform their processing. To achieve this, each instance constructor invokes the instance constructor of its parent class.

Since the design calls for an instance constructor for class animal to set a value for attribute alacrity and an instance constructor for class canine to set a value for attribute furColor, let’s use pseudocode to define a sequence of instance constructor methods that can facilitate making these settings when we create an instance of class fox:

• We indicated no instance constructor for class fox. In the absence of an instance constructor defined for a class, the runtime system will implicitly invoke the instance constructor for whatever next level in the class hierarchy provides one.

• The next level in the class hierarchy for which we have indicated the presence of an instance constructor is class canine, which would be defined to accept parameter values for furColor and alacrity. It would use the parameter value for furColor to set the corresponding attribute it contributes, but would in turn invoke the instance constructor of its parent class passing to it the parameter value for alacrity:

  class canine constructor(furColor,alacrity)
    invoke superclass instance constructor(alacrity)
    set attribute furColor to parameter value furColor

• The next level in the class hierarchy is mammal, for which we indicated no instance constructor. Again, in the absence of an instance constructor defined for a class, the runtime system will implicitly invoke the instance constructor for whatever next level in the class hierarchy provides one.

• The next level in the class hierarchy for which we have indicated the presence of an instance constructor is class animal, which would be defined to accept a parameter value for alacrity, using it to set the corresponding attribute it contributes:

  class animal constructor(alacrity)
    set attribute alacrity to parameter value alacrity

At the conclusion of this instance constructor invocation sequence, the instance constructor defined for each class within the ancestry hierarchy has had its chance to perform its processing. Afterward, the instance created (in this case, fox) now is in a state where it can be used.

Traversing the inheritance hierarchy of class fox shows an example of a single inheritance ancestry. Class fox has only one parent class (canine) which itself has only one parent class (mammal) which also has only one parent class (animal).

Class dog also follows this same ancestry path as fox, but dog also inherits from class domesticPet. This is an example of multiple inheritance; class dog has multiple parent classes. Consequently, when a dog instance is created, in addition to invoking the same instance constructors invoked for class fox, there is also the necessity to invoke the instance constructors of any classes in the ancestry path through domesticPet. Each object-oriented language supporting multiple inheritance has its own protocol for the sequence of invoking the instance constructors of these multiple inheritance paths. For example, in C++, the instance constructors of the multiple parent classes defined for a class are invoked in the same sequence as they appear on the definition of the class, and changing this sequence will change the order in which the instance constructors are invoked.

Effect of Inheritance upon Reference Variables

Reference variables enable a component to hold a pointer to an instance of a class. When a reference variable is defined in a program, it is associated with the type of class of which it is capable of holding a reference.⁶ However, a fundamental concept in object-oriented programming is that a reference variable may hold not only a reference to the type of class with which it is associated but may hold a reference to any type of child class inheriting directly or indirectly from its associated class. In short, a reference variable can hold a pointer to any type of class instance as long as the instance “is a” type of class assigned to the reference.

Because of this, a reference variable has an additional quality to be considered beyond just the instance of a class to which it is pointing. This additional quality is known as the “reference variable type .” There are two aspects of a reference variable type:

• Static type

• Dynamic type

Every reference variable has both of these two aspects of reference variable type. In some object-oriented languages, this concept of dynamic type is known as runtime type information (RTTI).

The static type refers to the type of class assigned with the definition of the reference variable. It is known as static because the programmer assigns a type of class to the reference variable and it will not change once the source code is compiled. Changing a static type to some other type of class requires a change to the source code.

The dynamic type refers to the type of class to which the reference variable is actually pointing during execution. It is known as dynamic because the type of class to which the reference variable is pointing may change from moment to moment during program execution. Changes to the dynamic type are a consequence of moving a pointer to an object into the reference variable.

When the type of class instance to which a reference variable is pointing at execution is the same as the one with which the reference variable is associated, then the static type and dynamic type of the reference variable are identical. When the type of class instance to which a reference variable is pointing at execution is a direct or indirect child class to the one with which the reference variable is associated, then the static type and dynamic type of the reference variable are different. Without inheritance, the static type and dynamic type of a reference variable would always be the same, and perhaps it would be unnecessary even to be aware of the concept of reference variable type . However, it is when inheritance is introduced that a dynamic type of a reference variable could be different from its static type.

A fundamental concept in object-oriented programming is that a reference variable can offer access only to those members of an instance that are defined by the class associated with its static type. That is, the static type of a reference variable determines which instance members are accessible through the reference variable. Accordingly, we can define two reference variables to two different abstraction levels within the same class inheritance hierarchy, like

this_enclosed_shape      type enclosed_shape
this_rectangle           type rectangle

and then create an instance of a rectangle into the reference variable with the static type defined for class rectangle, like

create object this_rectangle

and then copy the pointer to this instantiated class to the other reference variable, like

this_enclosed_shape = this_rectangle

At this point we have two reference variables both pointing to the same instance. Whereas reference variable this_rectangle has both a static type and dynamic type of rectangle, reference variable this_enclosed_shape has a dynamic type of rectangle, but its static type is enclosed_shape. Despite that both are pointing to exactly the same instance of a rectangle, we can access the method get_hypotenuse only through the reference variable this_rectangle. Access to the members of the rectangle instance through reference variable this_enclosed_shape is limited to only those members made available by class enclosed_shape, since that is the static type of the reference variable.

Effect of Inheritance upon Subsequent Maintenance

When used intelligently, inheritance is an indispensable object-oriented principle used in the design of software. When used indiscriminately, inheritance can cause difficulties with software design and maintenance. Steve McConnell states this very succinctly:

• “Inheritance is one of object-oriented programming’s most powerful tools. It can provide great benefits when used well, and it can do great damage when used naively.”⁷

Of the four pillars of object-oriented programming , inheritance is arguably the one that needs to be approached with the most caution. It is tempting to define elaborate class inheritance hierarchies once programmers become aware of its power. This can lead to class relationships that in subsequent maintenance cycles become too difficult to comprehend or require significant development effort to manage effectively.

Having been introduced with the first generation of object-oriented languages, inheritance has since fallen out of favor with many object-oriented scholars who now recommend using a technique known as composition. ⁸ This is not to suggest that inheritance should not be used, but simply that it requires some discipline on the part of software designers in deciding where it is applicable. The conventional wisdom these days is that inheritance hierarchies should remain shallow.⁹ I usually recommend to my students that three levels of inheritance are easily managed and that four levels still are acceptable, but once the hierarchy extends to five or more levels we are exposing ourselves and any subsequent maintenance programmers to potential difficulties managing and understanding the hierarchy.¹⁰

Meanwhile, inheritance enables writing entirely new classes that include members defined in other classes. This reuse of established components facilitates constructing new entities from those that already exist without the need to change the existing entities. Accordingly, a new class inheriting from an existing class can benefit not only from the code the parent class contributes but also from all the testing to which the parent class has already been subjected, minimizing the amount of work necessary to prepare a new subclass for use.

Effect of Inheritance upon Design

The extensive use of inheritance imposes certain constraints upon program design, including

Some object-oriented languages, among them Java and ABAP, have accommodated these design constraints as fundamental restrictions built into those languages. Neither language supports multiple inheritance , leaving singleness not so much a design choice as a design requirement. Both languages adhere to the static nature of inheritance hierarchies, but also provide support for using object composition as well. Both languages also facilitate subclass access to its superclass members by offering the protected access modifier for confining the visibility of some of its members only to its inheritors, avoiding the requirement for the superclass to otherwise make those members publicly visible.

Indeed, languages that lack support for multiple inheritance entirely eliminate the possibility of a classic design problem from ever creeping into software systems. Known as the diamond problem, ¹¹ it occurs when a class inherits from two parent classes, where at least one of these classes overrides a method of the same class from which both inherit. It gets its name from the shape of the relationships between classes composing this type of hierarchy, as illustrated in Figure 5-5.

Figure 5-5. Illustration of the diamond problem

Here we see through the connecting lines that class Student Employee inherits both from class Student and from class Employee, and further that classes Student and Employee both inherit from class Person, and that this constitutes a diamond relationship as depicted by the gray background shape.

Suppose class Person provides both the definition and implementation for a public method called getInformation, and that class Employee overrides the implementation of this method. It now becomes indeterminate which implementation will be applicable to class Student Employee, since the original implementation provided by Person is available via its Student superclass but the overridden implementation is available via its Employee superclass. Accordingly, since they both enforce the singleness design constraint, neither Java nor ABAP succumbs to the infamous diamond problem.

Postal Metaphor

The President of the United States lives in the White House. Mail addressed to the holder of this office requires something similar to the following:

• 1600 Pennsylvania Avenue NW

• Washington, D.C.

This would probably be enough for mail originating within the United States, but for parcels mailed from other countries, the following enhanced address might be required:

• 1600 Pennsylvania Avenue NW

• Washington, D.C.

• USA

Someday in the distant future it may be necessary to extend this address with other qualifiers , such as

• 1600 Pennsylvania Avenue NW

• Washington, D.C.

• USA

• North America

• Earth

• Solar System

• Gould Belt

• Orion Arm

• Milky Way

• The Universe¹²

Absurd, perhaps, but this illustrates a series of locations where each subsequent entry is more general than the one it follows.

Recall the red brick patio analogy from the chapter on Abstraction, where the level of abstraction above the patio determined the detail we could see. Let’s apply this same concept to intergalactic mail destined for the White House. First, let’s sort the address qualifiers in order from most general to most specific:

• The Universe

• Milky Way

• Orion Arm

• Gould Belt

• Solar System

• Earth

• North America

• USA

• Washington, D.C.

• 1600 Pennsylvania Avenue NW

They are now arranged such that we can ascend from 1600 Pennsylvania Avenue NW to a higher abstraction level to see all of Washington, D.C., and from there still higher to see all of the United States, and so on, moving from a distance of 5 meters above a patio at 1600 Pennsylvania Avenue NW to 5 kilometers above, to 5 parsecs above, until finally measuring our distance above the patio in light years.

The parcel posts (mail service providers) handling postal traffic corresponding to these abstraction levels might have designations as shown in Table 5-7.

In each case, the parcel post corresponds to a class capable of handling mail at that abstraction level . Each of these classes would have behaviors relevant to their abstraction levels, as indicated in Table 5-8.

The behaviors associated with each parcel post/class represent the postal capabilities available at that corresponding parcel post abstraction level. Where applicable, the behaviors accommodate moving a parcel up to the superordinate parcel post, laterally to a sibling parcel post, or down to a subordinate parcel post.

If we were to define a parcel post object reference variable associated with the class planet, its static type would be planet and the capabilities it could offer as services would be limited to these three:

• Route parcel to this star system post.

• Route parcel to other planet post of this star system.

• Route parcel to continent post of this planet.

Now, suppose a postal item intended for the President of the United States originated long ago in a galaxy far, far away. The intergalactic mail service facilitating postal traffic throughout The Universe would route this to the Milky Way parcel post. At this point the intragalactic mail service facilitating the Milky Way would take over and route this to the Orion Arm parcel post. It would pass through each successive, more-specific parcel post, including Earth, until it eventually reached the White House. The parcel post handling the northwest (NW) neighborhood of Washington, D.C. is at an abstraction level at which it has visibility to the detail of the roads in that neighborhood, including Pennsylvania Avenue. Meanwhile, roads (members of a neighbourhood) are at a level of detail beyond the perception of the parcel post handling Earth, which can recognize only its own star system, other planets in this star system, and continents on this planet. Similarly, continents (members of a planet) are at a level of detail beyond the perception of the parcel post handling Solar System, which can recognize only its own galaxy subsector, other star systems in this galaxy subsector, and stellar bodies orbiting the sun.

Although 1600 Pennsylvania Avenue exists as a detail in The Universe, it cannot be detected by the various parcel posts until we get to a level of abstraction close enough where this level of detail becomes visible.

Think of each parcel post as providing a virtual visor by which its mail carriers can see the detail of its own members. This visor offers visibility only to those members available through the static type of the parcel post. Despite handling a piece of mail with a more dynamic characteristic, it can provide visibility only at the level of detail the parcel post’s static type visor permits. That is, although the parcel may indeed have a street address in Washington, D.C., a mail carrier working at the Earth parcel post cannot perceive a city level of detail, and so has no behavior for routing the mail directly to any city.

For a different perspective, let’s suppose we have traveled the two and a half million light years from Earth to the Andromeda galaxy and have been able to establish an astronomical observatory on an earth-like planet, equipped with a telescope having the latest state-of-the-art technology available. Although we could aim the telescope toward the Milky Way galaxy, which we know has a Planet Earth with a President of the United States living in the White House at 1600 Pennsylvania Avenue NW, Washington, D.C., the magnifying power of our telescope would not enable us to perceive the Solar System, let alone Planet Earth, let alone Washington, D.C., even though we could be certain these would lie within our field of vision.

Cinematic Metaphor

Let’s suppose we are involved with filming a movie titled The Smith Family Goes To The County Fair. The script writers have called for different characters to be portrayed in the various scenes, and each character plays a specific role. Some of the required characters and their respective roles are shown in Table 5-9.

To fill these roles, we need actors, persons with the ability to portray a role in a movie.

Now that we have identified character, role, and actor, we can draw the analogy between film-making and object-oriented programming:

• A character in this movie is analogous to a reference variable in an object-oriented program.

• A role in this movie is analogous to the static type of a reference variable in an object-oriented program.

• An actor is analogous to the dynamic type of a reference variable in an object-oriented program.

This is illustrated in Table 5-10.

The roles require both male and female actors as well as adult and youngster actors. Accordingly, gender and age become specific character traits required for some of the roles, and the roles have been listed in the order they require specific gender and/or age traits. The roles for the Smith family characters require both gender and age-specific traits. They are followed by roles for contestants in the women’s and men’s three-legged races, which require specific gender but not specific age. They are followed by roles for owners of cars in the classic car show and drivers participating in the demolition derby, which require adult age but not specific gender. They are followed by the role for the winner of the pie-eating contest as well as the roles for spectators and attendees, which require neither specific gender nor specific age, and are simply listed as Shelly (winner of the pie-eating contest) or Extras (unnamed characters filled by those who respond to a casting call to be extras in a movie).

Before we begin shooting, our casting director will assemble the names of actors and begin the task of assigning actors to roles. Accordingly, the casting director will identify which types of actors can be assigned to which roles based on the gender and age requirements of each role, as shown in Table 5-11.

The role (static type ) Father of the Smith family calls for a male adult. The actor (dynamic type ) assigned to play that role needs to be both male and adult. In this case, the requirement of the role (static type) and the traits of the assigned actor (dynamic type) are identical; both are male adult. This same concept applies to the role Mother of the Smith family (female adult), to teen daughter of the Smith family (female youngster), and to preteen son of the Smith family (male youngster), where the requirement for the role matches the traits of the assigned actor. For reference variables, this is similar to both its static type and dynamic type being identical.

The role of Susan calls for a female actor. It may be played by an adult or a youngster, so long as the actor is female. In this case, the actor will have more of a specialization than is required for the role (she will be adult or youngster), but certainly has the necessary trait called for by the role (female). As such, the role will call upon the gender of the actor but not upon the age of the actor. So, even though the role may be filled by a youngster actor, the role does not require the actor to act in any way specific to being a youngster. Accordingly, the actor has excess capacity that is not required for the role. For reference variables, this is similar to its static type being more general than its dynamic type.

Similarly, the role of Chris calls for an adult actor. It may be played by a male or female, so long as the actor is adult. Again in this case, the actor will have more of a specialization than is required for the role (actor will be male or female), but certainly has the necessary trait called for by the role (adult). As such, the role will call upon the age of the actor but not upon the gender of the actor. So, even though the role may be filled by a female actor, the role does not require the actor to act in any way specific to being female. Here again the actor has excess capacity that is not required for the role, and again is similar to a reference variable static type being more general than its dynamic type .

Likewise, the role of Shelly calls for any actor. It may be played by a male or female , adult or youngster. Again in this case, the actor will have more of a specialization than is required for the role (he or she will be adult or youngster), but certainly has the necessary trait called for by the role (any). As such, the role will call upon neither the age nor the gender of the actor. So, even though the role may be filled by a male youngster actor, the role does not require the actor to act in any way specific to being male or being a youngster. Here again the actor has excess capacity that is not required for the role, and again is similar to a reference variable static type being more general than its dynamic type .

In all of these cases, the role makes no assumption about the actor playing the part, and does not call upon the actor to behave in any way beyond the requirements of the role. Accordingly, only those behaviors offered by the role can be portrayed by the actor. For reference variables, this means that only those behaviors offered by its static type can be requested by the corresponding acting object occupying the reference variable, despite the acting object having behaviors beyond those associated with the static type.

Our casting director will also want to assign understudies to some of these characters.

In those cases where an actor is assigned to a role that requires more specialization than a role for which the actor is being considered for understudy, the casting director does not need to be the least bit cautious of possibly assigning an actor to a role they cannot fill; the understudy assignment is always applicable to a role requiring less behavior than the role already assigned. For example, the actor playing the role of Frederick Smith (preteen son of the Smith family) is assigned to a role in which gender and age already are requirements. Accordingly, this actor can be assigned as an understudy for any of the other roles that require only male (characters William and Brian) or that require neither gender nor age (character Shelly). Accordingly, the casting director could cast the actor playing the Frederick Smith character as the understudy to the William, Brian, or Shelly characters without having to consider whether such a casting is incompatible. This is analogous to a generalizing cast between reference variables; it is always valid.

In those cases where an actor is assigned to a role that requires less specialization than a role for which the actor is being considered for understudy, the casting director will need to exercise caution over possibly assigning an actor to a role they cannot fill; the understudy assignment may not be applicable to a role requiring more behavior than the role already assigned. For example, the actor playing the role of Shelly (winner of pie-eating contest) is assigned to a role in which gender and age are not requirements. Accordingly, this actor can be assigned as an understudy for the role of William (contestant in men’s three-legged race) only if the actor playing Shelly is male, and can be assigned as an understudy for the role of Jessica Smith (teen daughter of the Smith family) only if the actor playing Shelly is both female and a youngster. Accordingly, the casting director could cast the actor playing the Shelly character as the understudy to the William or Jessica Smith characters only by first considering the attributes the actor possesses beyond the attributes required for their assigned role. When the actor playing the Shelly character is male, then he can be assigned to understudy the William character, and when a female youngster, can be assigned to understudy the Jessica Smith character. This is analogous to a specializing cast between reference variables; it may be valid, but it is only valid when the actor actually has the traits required for the role into which the actor would be cast.