1 Using Inheritance

We’ll look at 3 idioms describing good ways to use inheritance.

• Specialization

• Specification

• Extension

1.1 Specialization

When inheritance is used for specialization,

• The new class is a specialized form of the parent class

• but satisfies the specification of the parent in every respect.

The new class may therefore be substituted for a value of the parent.

This is, in many ways, the “classical” view of inheritance.

Recognizing Specialization

• A hallmark of specialization is that the base class

• has objects of its own

• may be processed in some applications without any contributions from the subclasses.

Consider this hierarchy. It’s quite likely that there are University Personnel who are neither teachers nor students (administrators, librarians, staff, etc.). As such, it’s entirely likely that some applications (e.g., printing a University telephone directory) will work purely from the attributes and functions common to all University Personnel.

At the same time, there are variant behaviors among the subclasses that would prove useful in some applications. For example, Students have grade point averages (and probably other grade info not shown in this diagram) that would permit us to print grade reports and transcripts.

1.2 Specification

Inheritance for specification

(Yeah, it’s a real pain that “specialization” and “specification” both look and sound so much alike. But I didn’t make up these terms. And the words really don’t mean anything like the same thing in their normal use, so just concentrate on what the words mean instead of what they sound like.)

takes place when

• a parent class specifies a common interface for all children

• but does not itself implement the behavior

• Sometimes called the “shared protocol” pattern

Defining Protocols

A protocol is a set of messages (functions) that can be used together to accomplish some desired task.

• The superclass defines the protocol.

• The subclasses implement the messages of the protocol in their own manner.

• Application code invokes the messages of the protocol without worrying about the individual methods.

Recognizing the Specification Idiom of Inheritance

• Base class typically has no instances (objects)

• Only objects are actually instances of subclasses

• Some operations may not even be implementable in the general base class

Example: Varying Data Structures

A common requirement in many libraries is to provide different data structures for the same abstraction.

• Allows application code writers to balance speed and storage requirements against expected size and usage patterns.

• Allows code in which the only mention of which data structure is being used comes when the actual objects are constructed

libg++

For example, prior to the standardization of C++, the GNU g++ compiler was distributed with a library called libg++.

This library as extraordinary for the variety of implementations it provided for each major ADT. For example, the library declared a Set class that declared operations like adding an element to a set or checking the set to see if some value were a member of that set. However, the Set class itself contained no data structure that could actually hold any data elements.

Instead, a variety of subclasses of Set were provided. Each subclass implemented the required operations for being a Set, but provided its own data structure for storing and searching for the elements.

• AVLSet stored the data in AVL trees (a balanced binary tree)

• BSTSet stored the data in ordinary binary search trees

• CHSet stored the data in a conventional hash table

• SLSet stored the data in a singly-linked list

In addition to these, there were subclasses for storing the elements in expandable arrays (similar to the std::vector), in dynamically expandable hash tables, in skip lists, etc.

The idea was that each of these data structures offered a slightly different trade off of speed versus storage, sometimes depending upon the size of the sets being manipulated.

Working with a Specialized Protocol

1.2.1 Abstract Base Classes

Adding to a Set Subclass

If we are working with libg++ This is OK:

void foo (Set& s, int x)
{
   s.add(x);
   cout << x << " has been added." << endl;
}
 
int main ()
{
   BSTSet s;
   foo (s, 23);
    ⋮

Adding to a General Set

But what should happen here?

 void foo (Set& s, int x)
 {
     s.add(x);
     cout << x << " has been added."   << endl;
 }
 
 int main ()
 {
     Set s;
     foo (s, 23);
       ⋮

• add() makes no sense if Set doesn’t have a data structure that can actually store elements.

• In fact, Set s; makes no sense.

How Do We Prevent This?

 void foo (Set& s, int x)
 {
     s.add(x);
     cout << x << " has been added."   << endl;
 }
 
 int main ()
 {
     Set s;
     foo (s, 23);
       ⋮

• We could add a method so Set() that prints an error message when add() is called.

• Better is to force a proper choice of data structure at compile time.

Abstract Member Functions

class Set {
      ⋮
    virtual Set& add (int) = 0;
      ⋮
};
   

• The = 0 indicates that no method exists in this class for implementing this message.

• add is called an abstract member function.

  • Subclasses must provide the actual methods (bodies) for these functions.

Abstract Classes

An abstract class in C++ is any class that

• contains an = 0 annotation on a member function, or

• inherits such a function and does not provide a method for it.

“Abstract classes” are also known as pure virtual classes.

Set as an Abstract Class

Set in libg++ is a good example of a class that should be abstract.

• We can’t possibly implement Set::Add
  • we need to do that in its subclasses.

Limitations of Abstract Classes

Abstract classes carry some limitations, designed to make sure we use them in a safe manner.

class Set {
   ⋮
  virtual Set& add (int) = 0;
   ⋮
};
  ⋮
void foo (Set& s, int x) // OK
  ⋮
 
int main () {
   Set s;  // error!
   foo (s, 23);
     ⋮

• You cannot construct an object whose type is an abstract class.

• You cannot declare function parameters of an abstract class type when passing parameters “by copy”.

  • but you can pass pointers/references to the abstract class type.

Abstract Classes & Specification

• Base classes in inheritance-for-specification are often abstract

• Base class exists to define a protocol

• Not to provide actual objects

2 The Observer Pattern

• A “design pattern” or idiom of OO programming

• Based on 2 mixins

• Observer

• can ask an Observable object for notification of any changes

• Observable

• will keep track of a list of Observers and notify them when its state changes

2.1 Applications of Observer

2.1.1 Example: Propagating Changes in a Spreadsheet

Anyone who has used a spreadsheet has observed the way that, when one cell changes value, all the cells that mention that first cell in their formulas change, then all the cells the mention those cells change, and so on, in a characteristic “ripple” effect until all the effects of the original change have played out.

There are several ways to program that effect. One of the more elegant is to use the Observer/Observable pattern.

Cells Observe Each Other

class Cell: public Observable, Observer
{
public:

The idea is that cells will observe one another.

• Suppose cell B2 contains the formula “2*A1 + B1”.

• Then B2 will observe A1 and B1.

  It will use the Observable::addObserver function to add itself as an observer of both those cells.

• If something were to happen to A1 that changes its value (e.g., we click on A1 and then enter a new value), then

  • A1 will call notifyObservers(), which goes through its list of observers, including, eventually including B2, notifying each one.

  • When B2 is notified, it can re-evaluate its formula, change its value, and notify its observers.

Changing a Cell Formula

2.1.2 Example: Observer and GUIs

A spreadsheet GUI contains a rectangular array of CellViews. Each CellView observes one Cell

• When value in a cell changes, it notifies its observers as we have already seen. Some of those observers are other cells, as described earlier. But one of those observers might be a CellView.

• The observing CellView then redraws itself with the new value

Scrolling the Spreadsheet

Not every cell will have a CellView observer.

• That’s because most of the cells in a spreadsheet are not actually visible at a given time.

• Whenever we scroll the spreadsheet GUI, the CellViews each register themselves with a different cell, depending on how far we have scrolled.

Model-View-Controller (MVC) Pattern

• A powerful approach to GUI construction

• Separate the system into 3 subsystems

  • Model: the “real” data managed by the program

  • View: portrayal of the model

    • updated as the data changes

  • Controller: input & interaction handlers

• View observes the Model

This pattern has many advantages. GUI code is hard to test. Keeping the core data independent of the GUI means we can test it using unit or similar “easy” techniques. We can also change the GUI entirely without altering the core classes. For example, my implementation of the spreadsheet has both a graphic form (as shown in the prior section) and a text-only interface that can be used over a simple telnet connection.

Separating the control code means that we can test the view by driving it from a custom Control that simply issues a pre-scripted set of calls on the view and model classes

MVC Interactions

How do we actually accomplish this?

• The Oberver/Observable pattern is one important component of the MVC.
  • It allows the Model classes to notify appropriate parts of the GUI without knowing anything detailed about the GUI class interfaces.

3 Abusing Inheritance

Just as there are idioms for good uses of inheritance, there are some that programmers have tried, and that new programmers often “rediscover”, that are really not advisable.

3.1 Construction

Occurs when a subclass is created that uses the superclass as the implementing data structure

• May violate the is-a relationship normally indicated by inheritance.

 struct Cell {
    int    data;
    Cell* next;
 
    Cell (int i) {data = i; next = this;}
    Cell (int i, Cell* n)
                 {data = i; next = n};
 };
    

Here is an example, drawn from a textbook that shall remain anonymous. This cell (no relation to the notion of a cell in a spreadsheet) class defines a “utility” linked list node.

 class CircularList {
     Cell* rear;
 public:
     CircularList();
     bool empty();
     void addFront (int);
     int removeFront ();
     int addRear (int);
 };
    

We can use this to create a circular list (a linked list in which the last node in the list points back to the first node). Circular lists are useful in that they support efficient adding at either end and removing from one end.

 class Queue: public CircularList {
 public:
    Queue();
    void enterq (int x) { addRear(x);}
    int leaveq()       {removeFront();}
    // inherit bool empty();
 };


 class Stack: public CircularList {
 public:
    Stack();
    void push (int x) {addFront(x);}
    void pop() {removeFront();}
    // inherit bool empty()
 }; 

This list could be used to implement stacks and queues.

So we can write applications like the following:

    Queue q;
    q.enterq (23);
    q.enterq (42);
    q.leaveq ();
    bool b = q.empty();
    q.addFront (21);  // oops!

The last call is a problem. We should not be able to add to the front of a queue.

• Public inheritance makes too much additional interface visible

• need to hide the underlying operations.

3.1.1 Private Inheritance

 class Queue: private CircularList {
 public:
    Queue();
    void enterq (int x) { addRear(x);}
    int leaveq()       {removeFront();}
    CircularList::empty;
 };


 class Stack: private CircularList {
 public:
    Stack();
    void push (int x) {addFront(x);}
    void pop() {removeFront();}
    CircularList::empty;
 };

It is possible to solve this problem by private inheritance. We inherit, but all inherited members are private in the subclass.

Private inheritance hides inherited members from application code.

• It can be used to share data structure and methods without affecting the interface

• Contrast this with public inheritance, where the major motivation is to share protocol/interface.

3.1.2 What’s Wrong with This?

• With private inheritance (or judicious use of protected members), inheritance for the purpose of code sharing is possible,

• But

• the resulting inheritance hierarchy is often counter-intuitive and may clash with other inheritance motivations.

• it is usually easier to do the same thing using aggregation/composition rather than inheritance:

 class Queue: {
    CircularList c;
 public:
    Queue();
    void enterq (int x) { c.addRear(x);}
    int leaveq()     {c.removeFront();}
    bool empty()     {return c.empty();}
 };

Doesn’t this just seem simpler?

• With inline function expansion, this need not be any slower than the inherited versions.

3.2 Subset != Subclass

• We often say that inheritance captures an “is a” relationship.

• But “is a” is vague and subject to many interpretations.

• A common interpretation is “is a specialized form of”.

3.2.1 A Bird in the Hand

 class Animal;
 class Bird: public Animal { ...
 class BlueJay: public Bird { ...

• Seems logical, right?

3.2.2 is Worth 2 in the Sky?

Let’s postulate some members for Birds:

 class Bird: public Animal {
    Bird();
    double altitude() const;
 
    void fly();
       // post-condition: altitude() > 0.
      ⋮
 };
 
 class BlueJay: public Bird
 {
     ⋮

3.2.3 Is an Ostrich a-kind-of Bird?

 class Ostrich: public Bird
 {
   Ostrich();
   // Inherits
   // double altitude() const;
 
   // void fly();
   //post-condition: altitude() > 0.

• Now, Ostrich can provide its own method for fly()

 void Ostrich::fly()
 //post-condition: altitude() > 0.
 {
   plummet();
 } 

• but it can’t satisfy that post-condition.

• An unpleasant surprise for someone traversing a list of Bird’s.

3.2.4 Substitutability

The ostrich/bird hierarchy violates the substitutability principle:

• Class A should be a public subclass of B only if a value of class A can logically be substituted wherever a value of type B is expected.

• Instead of is-a, perhaps we should say that public inheritance captures an “observes the protocol of” relation.

• You can view this dilemma as a failure of analysis:

• Who said all birds could fly?

• A FlyingBirds subclass of Bird would clarify the situation.

• Anyone want to tackle a platypus?

3.2.5 Fixing a Broken Hierarchy

When two classes share code and data but do not share an is-a (protocol) relationship.

• Mouse & Tablet

• Stack& Queue

• Better to factor shared code and data into a common parent class

• e.g., Pointing Device

• or factor shared code and data into a common implementation structure, accessed via composition

• e.g., implement Stack & Queue via a LinkedList data member