The impoliteness of overriding methods

[Benjamin Thaut]

Am 20.12.2012 20:35, schrieb H. S. Teoh:>>
 >> So basically you suggest adding a language feature to cover up
 >> library developer's poorly designed API? IMO, if you want to provide
 >> a frozen API under the current inheritance design, you should use
 >> pimpl design pattern in the first place and not ask for features to
 >> solve the problem after the fact.
 >
 > Yeah, it doesn't make sense for the base class implementor to say "you
 > must call function X after you're done function Y". The base class API
 > should be *designed* so that function X *will* be called after function
 > Y, no matter what the derived class code does.
 >
 > OO code that breaks if methods are called in the wrong order (or certain
 > methods fail to get called) is broken by definition. The object's
 > internal state must remain consistent no matter what sequence its
 > methods are called. This is a fundamental tenet of OO design.
 >
 >
 > T
 >

It makes perfect sense if you have certain preconditions. Something like

1) As little API changes as possible, so the customer can easily port to 
the new version
2) The original API was not designed by you, and never did anticipate 
that in the future the method can not be abstract anymore.

If you have a codebase that is 10 years old, you will get such issues 
quite often. And unfortunately in C++ and D there is no good way to deal 
with such changes. (At least none that I know of)

Kind Regards
Benjamin Thaut