Not if the third party developer intends to override it in his own subclasses.
Documentation may solve the issue, but this goes against the "just works" philosophy.
The root of the problem is versioning. Your class was developed against version 1 of the base class. You expect further changes in implementation of the base class should not materially affect your running code.
To achieve this, one of the sacrifices is the all methods are not overridable by default (i.e. not virtual), but instead have to be explicitly declared virtual AND the subclass has to explicitly state they wish to override the base class.
the problem runs deeper. When version 2 of the ThirdParty class ships, suddenly your class doesn't work. If another team has subclassed your class and overridden your printResult routine, you are effectively stuck. You can't take in bug fixes that exists in version 2 and the other team effectively couldn't move forward either. Remember, this is best practice OO, and there really hasn't been any changes to the interface. So effectively this is like version 1.01.
It is namespace pollution of a very subtle and devious kind.
Comments
> wouldn't private methods solve that problem?
Not if the third party developer intends to override it in his own subclasses.
Documentation may solve the issue, but this goes against the "just works" philosophy.
The root of the problem is versioning. Your class was developed against version 1 of the base class. You expect further changes in implementation of the base class should not materially affect your running code.
To achieve this, one of the sacrifices is the all methods are not overridable by default (i.e. not virtual), but instead have to be explicitly declared virtual AND the subclass has to explicitly state they wish to override the base class.
Why is it reasonable or desirable for a programmer to expect that switching to a new version of a library should have no effect on dependent code?
the problem runs deeper. When version 2 of the ThirdParty class ships, suddenly your class doesn't work. If another team has subclassed your class and overridden your printResult routine, you are effectively stuck. You can't take in bug fixes that exists in version 2 and the other team effectively couldn't move forward either. Remember, this is best practice OO, and there really hasn't been any changes to the interface. So effectively this is like version 1.01.
It is namespace pollution of a very subtle and devious kind.