

Raganwald on Inheritance - 0x44
http://weblog.raganwald.com/2008/04/is-strictly-equivalent-to.html

======
ambition
Summary: If superclass has method X with behaviour Y, do not override X to
have behaviour Z in a subclass, because this violates the spirit of
inheritance semantics.

To be fair, his version is long, persuasive and well-written. And it has
references.

~~~
Retric
Granted there is a loss of clarity when a sub class changes a parent classes
behavior. But, there are still times where it can be useful.

EX: You want to add a section to an online banking app that handles IRA
accounts. It would be nice to reuse as much of the logging, balance transfer,
and UI as possible but you don't want to alter well tested core classes. So
you use inheritance to get something that works and is reasonably clean until
you can refactor a cleaner solution.

~~~
0x44
It is likely I'm misunderstanding, but why would you use inheritance instead
of composition in your example?

~~~
ambition
I bet the alternatives that were considered were:

    
    
        class Parent
        {
         void a() {...}
         void b() {...}
         void c() {...}
         void d() {...}
         ...
         void zzz() {...}
        }
        
        class B 
        {
         Parent m_a;
         void a() {m_a.a()}
         void b() {m_a.b()}
         void c() {m_a.c()}
         void d() { specialized logic }
         ...
         void zzz() {m_a.zzz()}
    
        }
    

vs.

    
    
        class B : Parent
        {
         void d() { specialized logic }
        }

~~~
Retric
Your first example works fine until void a() Parent.a() calls Parent.d() and
you need the code to call B.d().

An interface also works but you end up cutting and pasting a lot of the same
code between the two classes.

------
wallflower
Unfortunately, I've spent more-time-than-I-should time over the years
debugging issues where a subclass was supposed to have overriden a superclass
method's behavior but the subclass method had the wrong method signature (and
thus was never called). Console log statements never lie..

~~~
raganwald
The idea that different methods can have the same name but different
signatures presents many challenges. IMO, if you are going to live with the
drawbacks, you ought to be able to enjoy all of the benefits, such as you will
find in full-features MOPs like in Common Lisp or pattern-matching languages
like Haskell.

BTW, Ruby and Java both solve this problem. In Java, use the @override
annotation. If you are not overriding a method, you get a compiler error.

Ruby "solves" the problem by only having one method per name. But you can mix
in some magic and get pattern matching if you want.

