Item 37: Never redefine an inherited nonvirtual function.

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.