Lecture of 27 January 1994

Hierarchy

Multiple Inheritance

• To paraphrase Stroustrup, multiple inheritance (MI) is not hard to implement once one defines what it means. Unfortunately, people have not come to general agreement about exactly what MI entails.
• In essence, MI entails having a class inherit representation and behavior from more than one class. This means that rather than having a single base class, the new class would have multiple base classes.
• One popular MI technique (from CLOS) is to use what are called mixin classes. A mixin class is designed to augment the behavior of a class by providing just those components and behavior that are required for some other class to exhibit a particular property.
• Booch gives a mixin example in which he defines the classes Plant, FlowerMixin, and FruitVegetableMixin. He then goes on to define other classes as follows:

  class Rose: public Plant, public FlowerMixin ... class Carrot: public Plant, public FruitVegetableMixin ... class Cherry: public Plant, public FruitVegetableMixin, public FlowerMixin ...

  Aggregation

• Don't forget that aggregation, including objects in a part-of hierarchy also represents a powerful hierarchical structuring tool.
• Aggregation is not new to O-O languages, but O-O languages have the benefit of being able to group hierarchically across two dimensions:
  • aggregation, and
  • inheritance

Typing

• Booch uses the word type synonymously with class, however as he admits, the concepts are clearly different. Consider the fact that int, float, and char are indeed types in the C++ language, however, they certainly do not represent classes. One cannot inherit representation or behavior from these types, but one may use them as aggregate elements of new classes.
• Sethi states that a programming language's type system is said to be strong if it accepts only type-safe expressions, that is, expressions in which the operators accept operands of the given types. If a type system is not strong, it is said to be weak.
• In addition, a system may support both dynamic and static binding of types to objects or references to objects.
• Eiffel is strongly typed, Smalltalk is untyped, due to the fact that any method (operation) may be applied to any object. Thus, in a sense, there are no type-unsafe expressions. C++, on the other hand provides programmers with specific methods of escaping from the type system (via the use of casts), effectively destroying the strong typing of the language.
• Strong typing provides certain benefits:
  • We can be certain that a program will not fail due to evaluating a type-unsafe expression.
  • We can enforce restrictions on behavior by guaranteeing that a method can only be applied to an object of the correct type.
• On the other hand, there are drawbacks:
  • If language is implemented by a compiler (as are most strongly typed languages), then minor modifications to class definitions may require significant recompilation. (In our word counting example, any change to a .h file will necessitate a recompilation of any piece of code including that .h file.
  • It may be difficult or impossible to construct collections of heterogeneously typed objects or aggregations in which the exact type of the object parts need not be known.
• Strong typing imposes concrete demands on operands, whereas weak typing provides a more abstract view of objects.
• Types can be either manifest or latent. A type is manifest if it is specifically represented as an entity in itself, and latent if it cannot be directly consulted. many strongly-typed languages provide strongly typed references to objects, however the objects themselves may be untyped. Many weakly-typed languages provide untyped references to objects, however the objects themselves may be latently typed.
• Thus in C++ you can tell the type of a pointer, but once you get to the storage to which the pointer refers, the type of the object is unknown. Whereas in lisp object systems, the type of the pointer is unknown, but the object referred to contains information that can (at least indirectly) reveal its type.
• Booch presents an example of a class manipulation void pointers to implement an Inventory class which can contain heterogeneous objects, that is, objects having different types. I do not recommend that one enter into such activities lightly. There be dragons there. There is now a proposal for ANSI C++ that contains a mechanism for run-time type identification (RTTI), however, using such types can often lead to a less O-O programming style, in which myriad switch control structures checking the types of objects are employed. having such code structures does not lead to easily modifiable, highly maintainable programs.
• It is sometimes that case that we need to change the type of an object. If we need to change objects from class A into objects from class B, there are two C++ idioms for doing this:
  • A class B constructor can take an argument of type A
  • A class A conversion function (with the name B can be defined in class A to take an argument of type A
  For more information on this, see Stroustrup ppg. 572--575. If one were to try to employ both of the solutions proposed above, errors of ambiguity could result because there would be two distinct ways to achieve the desired type conversion.

  The first mechanism would usually be employed if B is considered to be the more complicated type. The second would be employed if B were considered to be the simpler type.

• Binding of types to objects and references to objects can occur both statically and dynamically. In languages like Smalltalk, references to objects are untyped, and all objects are accessed through pointers. In C++ references can be bound statically or dynamically. In addition, all references are typed, but some flexibility in using these references is provided. In particular, a reference to any object in C++ may be treated as if it is a reference to any class from which the object's class is derived. This provides a limited kind of polymorphism.
• Polymorphism is a property of functions. A function is polymorphic if it may take arguments whose types may vary. In essence, then, any C++ function taking a reference argument is polymorphic.