Back to Item 36: Differentiate between inheritance of interface and inheritance of implementation.
Continue to Item 38: Never redefine an inherited default parameter value.

Item 37: Never redefine an inherited nonvirtual function.

There are two ways of looking at this issue: the theoretical way and the pragmatic way. Let's start with the pragmatic way. After all, theoreticians are used to being patient.

Suppose I tell you that a class `D` is publicly derived from a class `B` and that there is a public member function `mf` defined in class `B`. The parameters and return type of `mf` are unimportant, so let's just assume they're both `void`. In other words, I say this:

    class B {
    public:
      void mf();
      ...
    };

    class D: public B { ... };

Even without knowing anything about `B`, `D`, or `mf`, given an object `x` of type `D`,

    D x;                          // x is an object of type D

you would probably be quite surprised if this,

    B *pB = &x;                   // get pointer to x

    pB->mf();                     // call mf through pointer

behaved differently from this:

    D *pD = &x;                   // get pointer to x

    pD->mf();                     // call mf through pointer

That's because in both cases you're invoking the member function `mf` on the object `x`. Because it's the same function and the same object in both cases, it should behave the same way, right?

Right, it should. But it might not. In particular, it won't if `mf` is nonvirtual and `D` has defined its own version of `mf`:

    class D: public B {
    public:
      void mf();                  // hides B::mf; see Item 50

      ...

    };

    pB->mf();                     // calls B::mf

    pD->mf();                     // calls D::mf

The reason for this two-faced behavior is that nonvirtual functions like `B::mf` and `D::mf` are statically bound (see Item 38). That means that because `pB` is declared to be of type pointer-to-`B`, nonvirtual functions invoked through `pB` will always be those defined for class `B`, even if `pB` points to an object of a class derived from `B`, as it does in this example.

Virtual functions, on the other hand, are dynamically bound (again, see Item 38), so they don't suffer from this problem. If `mf` were a virtual function, a call to `mf` through either `pB` or `pD` would result in an invocation of `D::mf`, because what `pB` and `pD` really point to is an object of type `D`.

The bottom line, then, is that if you are writing class `D` and you redefine a nonvirtual function `mf` that you inherit from class `B`, `D` objects will likely exhibit schizophrenic behavior. In particular, any given `D` object may act like either a `B` or a `D` when `mf` is called, and the determining factor will have nothing to do with the object itself, but with the declared type of the pointer that points to it. References exhibit the same baffling behavior as do pointers.

So much for the pragmatic argument. What you want now, I know, is some kind of theoretical justification for not redefining inherited nonvirtual functions. I am pleased to oblige.

Item 35 explains that public inheritance means isa, and Item 36 describes why declaring a nonvirtual function in a class establishes an invariant over specialization for that class. If you apply these observations to the classes `B` and `D` and to the nonvirtual member function `B::mf`, then

- Everything that is applicable to `B` objects is also applicable to `D` objects, because every `D` object isa `B` object;
- Subclasses of `B` must inherit both the interface and the implementation of `mf`, because `mf` is nonvirtual in `B`.

Now, if `D` redefines `mf`, there is a contradiction in your design. If `D` really needs to implement `mf` differently from `B`, and if every `B` object — no matter how specialized — really has to use the `B` implementation for `mf`, then it's simply not true that every `D` isa `B`. In that case, `D` shouldn't publicly inherit from `B`. On the other hand, if `D` really has to publicly inherit from `B`, and if `D` really needs to implement `mf` differently from `B`, then it's just not true that `mf` reflects an invariant over specialization for `B`. In that case, `mf` should be virtual. Finally, if every `D` really isa `B`, and if `mf` really corresponds to an invariant over specialization for `B`, then `D` can't honestly need to redefine `mf`, and it shouldn't try to do so.

Regardless of which argument applies, something has to give, and under no conditions is it the prohibition on redefining an inherited nonvirtual function.

Back to Item 36: Differentiate between inheritance of interface and inheritance of implementation.
Continue to Item 38: Never redefine an inherited default parameter value.