On 28/09/2012 09:27 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> Heh. It amuses me that run-time polymorphism via inheritance is /the/
>> central contribution of the OO movement, and here I am reading a book
>> warning me not to use inheritance under any circumstances unless
>> absolutely unavoidable...
>
> Does it explain why?

In most OO languages (e.g., Java, Eiffel, Smalltalk...) you can override 
any method. Java adds a "final" keyword which you can use to disable 
overriding on a given method (presumably resulting in a small 
performance benefit). Eiffel of course achieves the same thing 
automatically using whole-program analysis - then again, Eiffel doesn't 
support dynamic code loading like Java does.

Regardless, C# turns this backwards. In C#, by default you /cannot/ 
override anything, unless you explicitly turn it on by writing 
"virtual". Meaning that if the author of some class didn't foresee the 
potential need to subclass it, you may not be able to override the 
necessary methods.

But that's nothing. According to the author of this book, you should 
mark all classes as "sealed", preventing them from ever being 
subclassed. Every class should be sealed, and no methods should be 
marked virtual, unless absolutely necessary.

Apparently it is "very hard" to design a class in such a way that it can 
be subclassed correctly. So you should only allow this possibility where 
a class has been explicitly designed with the intention of being 
subclassed later. In all other cases, you should disable subclassing, 
because if you didn't design for it, it won't work anyway.

All of which strikes me as a little baffling. I mean, I know that 
inheritance is overused and collaboration is underused. But this just 
seems excessive!

Then again, this is from the same book that explains how to write 
destructors (i.e., "don't") before explaining how to write methods with 
named arguments. The former is an obscure and very dangerous feature 
which you should never use, under any circumstances, ever. The latter is 
a pretty simple and common feature. Really, the order of presentation 
here seems rather strange. Rather than a coherent introduction, it seems 
like a random grab-bag of "features", in no particular order...

Post a reply to this message