The impoliteness of overriding methods

[Dan]

On Thursday, 20 December 2012 at 07:48:12 UTC, foobar wrote:
>
>
> This is trivially implemented with a simple OO design pattern 
> in any usual OO language:
>
> class Base {
>   public override precious() {...}
>   private void myPrecious() {
>     before();
>     precious();
>     after();
>   }
> }
>
> class Derived {
>   override precious() {...}
> }
>
> Having syntax sugar is redundant given how simple this pattern 
> is.

I think it is more than syntactic sugar and in this case it is 
trivial because you as a designer of Base anticipate only one 
level of Derived. But, assume there are to be 2, 3, 4, or more 
levels of derivation. In fact, maybe you don't know how many 
levels there will be. For a chain of B->D1->D2->D3 I don't see 
how you can up front get the same effect this way. At the level 
of D2, base will skip the implementation of precious() in D1. At 
the level of D3, base will skip the implementation of precious() 
in D1 and D2, etc. Chaining is lost beyond the first level. It is 
as if something is done in one direction, you want it done the 
other and you provide an example that does the reversion as long 
as there are only two entries. It is not truly a general solution.

 From the article: "If you chain more than two levels of 
subclasses, BETA scales better because you don’t need to keep 
coming up with new names."

Thanks
Dan