Lecture of 31 January 1995

Code now, text later! #include <iostream.h> class Animal{ public: virtual void name () = 0; // // The keyword virtual indicates that this member function may be // redefined by derived classes and that if I treat a derived class // object as an Animal, then the derived class member function is // executed. virtual void tease () = 0; // // The = 0 definition of name and tease indicates that objects of class // Animal cannot be constructed because these behaviors are undefined // for the general class of animals, but must be well-defined for // sub- or derived classes of animal for which specific objects can // be constructed. // In Smalltalk, such a member is called a subclass responsibility. // In C++ it is called an abstract virtual function, and the class // Animal is referred to as an abstract base class because no (physical) // objects belonging to the class can exist. virtual void sound (); }; void Animal::sound() { cout << "(nothing)"; } class Snail : public Animal{ // The class Snail is derived from Animal. // It thus must redefine all the abstract virtual functions of Animal, // that is, name and tease. public: Snail (){} virtual void name (); virtual void tease (); }; // Snail does not redefine sound, therefore, when the sound member // function of a snail is invoked, the one inherited from the // Animal class is used. void Snail::name() { cout << "snail"; } void Snail::tease() { cout << "pour salt on"; } // The livestock class defines a non-virtual tease function which can // be inherited by all derived classes of livestock. // It also redefines the sound function, but leaves the // name member function virtual, thus derived classes of Livestock must // define a name member function. class Livestock : public Animal{ public: virtual void name () = 0; virtual void tease (); virtual void sound (); }; void Livestock::tease () { cout << "pull the tail"; } void Livestock::sound () { cout << "Moo"; } class Cow:public Livestock{ public: Cow (){} virtual void name (); }; void Cow::name() { cout << "cow"; } class Buffalo:public Livestock{ public: Buffalo (){} virtual void name (); }; void Buffalo::name () { cout << "buffalo"; } // The harass function takes an Animal reference argument. // Functions that take such a reference to a class such as Animal // may actually be passed a reference argument object of a derived // class of Animal. When an animal virtual member function is invoked // within the body of harass, the member function defined by the // argument object's class is used. void harass(Animal &a) { cout << "If you "; a.tease (); cout << " a "; a.name (); cout << ", then it will say "; a.sound (); cout << "." << endl; } int main() { Snail s; Cow c; Buffalo b; harass(s); harass(c); harass(b); return 0; }

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 has-a 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.

$Id: Jan.31.html,v 1.1 1995/02/22 15:05:16 jnw Exp jnw $