On 9/29/2012 3:19, Orchid Win7 v1 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...
>>
>> So, what's their solution? You have to reinvent the wheel all the time?
>
> Use interfaces instead.

Sounds like a stupid book. I wouldn't trust its advice.

Don't use inheritance unless you're obviously making a subclass of the thing 
you're inheriting from. Don't use polymorphic dispatch unless you intended 
to use polymorphic dispatch.

I think of all the code in my entire project, I have exactly one set of 
routines that inherit from some other routine I wrote, and they're basically 
type-specific widgets for displaying the results of searching over 
collections of various kinds of documents.

I have a bunch of .. well, database connectors, one for each table, that all 
inherit from the general "database connector."  I have a bunch of protobufs 
that all inherit from "generic protobuf".

Otherwise, there's virtually no inheritance in my work code.

I have a game, where I do indeed have some inheritance, but where multiple 
inheritance might very well have worked out better. For each stackable 
screen (say, you have a help screen on top of a file selection screen on top 
of a start game screen on top of a top-level-menu screen), it inherits from 
the appropriate superclass (input-blocking screen, input-blocking screen 
with timeout, etc).  Other than that, again, very general.

IME, libraries often have classes you'd almost never use as is, which you 
can inherit from, and applications generally have very few classes you 
actually inherit from. And for the latter, you almost always know when 
you're writing the base class that you're going to be inheriting from it.

-- 
Darren New, San Diego CA, USA (PST)
   "They're the 1-800-#-GORILA of the telecom business."

Post a reply to this message