The base class should protect itself from harmful overrides. In keeping with the open/close principle, it should be open to extension but closed to modification. Overriding update
is a harmful modification of the base class's intended behaviour. In your example, there is no benefit in overriding update
because both A::update
and B::update
are private methods that deal with private variables. There isn't even an expectation that they should be executed together judging by your exception in B::foo
. If B::update
was named differently, there wouldn't be anything wrong with your implementation. It would probably be OK anyway: since no language I know of will let you override a private method, B::update
could hide A::update
rather than overriding it.
Depending on the language, you can limit which methods can be overridden in different ways. Some languages require an indicator (a keyword or attribute usually) that a method can be overridden, others to show that it can't. Private methods are generally not overridable, but not all languages have access modifiers at all, and everything is effectively public. In this case you would have to use some kind of convention as suggested by @PoByBolek.
tl;dr: Children have no business with their parents' privates.