Effective C++, 2E | Item 37: Never redefine 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.
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.