Lecture Notes for Advanced Programming II

20 November 2003 - Polymorphism and Inheritance

Polymorphism

• Polymorphism makes the type system more flexible, but still safe

• Casting eliminates differences between types; int and float; destructive (lost precision) and complicated (casting between a double and a string)

• Overloading makes many types respond to the same operators; int, float, and string addition; semantically dubious (string multiplication) and complicated (string multiplication, conversions and the n-by-m problem)

• Templates abstract away types when not important; the size of a T list; implementation problems (code bloat, funny rules), some type aspects are important (equal T values)

Subtype Polymorphism

• Subtype polymorphism involves related types exhibiting similar behaviors.

• Example: numbers.

  • There are many number types (natural, integer, rational, floating point, complex); they all respond to arithmetic operators.

  • Casting and templates are not appropriate (information loss and type specific operators).

  • Overloading (without casting) is appropriate, but how should it be organized.

• Subtype polymorphism models the behavioral similarities among a set of related types.

General Approach

• A parent class models the abstract, generic behavior of the related types as an abstract, generic type - for example, class Number.

• Each specific type is modeled as a child of the parent class - for example, class Integer : Number or class Complex : Number.

• Rule of thumb - the longest path from root to leaf should be short, two or three classes.

  • Longer paths are complicated because information is spread out.

Subtype Polymorphism and Inheritance

• Inheritance provides both prototype sharing and polymorphism.

• Parent prototypes are copied to the children to provide behavioral sharing.

  • "behavior" means behavior at the prototype, not code sharing.

  • Behavior sharing defines the consistent behavior property among the related types.

• Polymorphism comes from the parent-child relation through is-a inheritance.

  • A child type is-a kind of parent type.

    • An integer is a kind of number.

  • Shared prototypes makes is-a inheritance useful.

    • The child really is-a kind of parent.

Recognizing Subtype Polymorphism

• Subtype polymorphism should be designed into the code.

  • It reduces design effort.

    • design the parent class once and the child classes follow along.

  • It reduces coding effort.

    • The parent-child relation neatly and clearly factors and emphasizes coding obligations

  • It increases syntactic clarity.

    • The parent class sets the notation (operators) for all its children, rather than having notation specific to each child.

  • It Increases semantic clarity.

    • A number is a number, and it gets added.

Missing Subtype Polymorphism

• Missed opportunities for subtype polymorphism smell like type-based if or case statements.

  • For example

    • An expression is a node; a node is one of three types: number, variable, or operation.

      void expression::write(ostream & os) const {
        if (expr_t == operation) {
          left->write(os);
          os << " " << prep << " ";
          right->write(os);
          }
        else if (expr_t == number)
          val.write(os);
        else {
          assert(expr_t == variable)
          os << prep;
          }
        }
      

    • Define the parent class node and the children class number_node : node, class variable_node : node, and class operator_node : node.

  ---

  Another Example

  • For example

    • A student record can be for a graduate or undergraduate.

      if (ch == 'u')
        record.type = undergrad;
        // read undergrad information
      else
        record.type = graduate;
        // read graduate information
      

    • Define a parent class record and children class grad_rec : record and class ugrad_rec : record.

    • The book does something slightly different and slightly less clean.

Points to Remember

• Missed subtype polymorphism looks like type-based if or case statements.

• Design for subtype polymorphism.

  • What is the common set of similar behaviors?

    • This is the parent class.

  • What things behave similarly (have the same set of prototypes).

    • These are the child classes.

• Use inheritance to share prototypes, not code.

  • "Behavior" means prototype, not code.

  • Code-sharing inheritance was the oo tragedy of the '80s.

  • Code-sharing inheritance hierarchies are narrow, brittle, and complex.

  • Break this rule only under subtype polymorphism.

    • Factor common code from children to parent.

    • Don't force parent code on the children.

This page last modified on 20 November 2003.