The impoliteness of overriding methods

Paulo Pinto pjmlp at progtools.org
Thu Dec 20 02:07:48 PST 2012


On Thursday, 20 December 2012 at 09:07:35 UTC, Benjamin Thaut
wrote:
> This polite overriding is a nice idiom. But it does not solve 
> the most frequent problem I have at work (in C++)
>
> Assume you have a customer facing class they derive from to 
> implement own features.
>
> abstract class Base
> {
>   abstract void doStuff();
> }
>
> The customer now derives from this class and implements 
> doStuff. Because it is abstract he does not call the base 
> implementation.
>
> Now you have to do some changes and suddenly the doStuff method 
> is no longer abstract and does something important that should 
> always be executed.
>
> abstract class Base
> {
>   void doStuff(){ prepareSomething(); }
> }
>
> The best you can do is put a line into the changelog "make sure 
> to call the base implementation of Base.doStuff...". Which the 
> customer most likely won't read and thus usually will fill a 
> issue report with the Support deparment, because the code 
> breaks.
>
> If there would be some kind of attribute supported by the 
> compiler, such as that the compiler ensures that the base 
> implementation is always called if the function is annotated 
> with this attribute the customer would automatically be 
> reminded by the compiler, and this would not be an issue.
>
> It could look something like this:
>
> abstract class Base
> {
>   @mustcall void doStuff(){ prepareSomething(); }
> }
>
> Making a helper method that is called instead of doStuff is 
> usually not an option, because the customer might have calls to 
> doStuff in his code, which would still lead to a wrong 
> execution path.

Related to this, you might find interesting to read this paper
about the Fragile Base Class problem,

http://www.cas.mcmaster.ca/~emil/Publications_files/MikhajlovSekerinski98FragileBaseClassProblem.pdf

Also related to this problem there was a school of though in the
late 90's about component programming (similar to what Go uses)
where OO only with composition is proposed.


http://www.amazon.com/Component-Software-Object-Oriented-Programming-Addison-Wesley/dp/032175302X/ref=pd_sim_sbs_b_2

(First edition used Component Pascal, which incidentally has
inheritance)

I do realize this does not solve your problem, just sharing
information.

Paulo



More information about the Digitalmars-d mailing list