🚀 go-pugleaf

In <4ctomq$1pi8@hopi.gate.net>, feathers@gate.net (Michael Feathers) writes:
>This may seem like a quibbling point, but in OOP it should be a natural
>assumption (because of polymorphism) that all objects of derived
>classes should perform in a manner appropriate to their class in
>the context of their base classes interfaces.  This is information
>hiding, in much the same way as function names hide implementation 
>yet provide semantic information.  If this is not the case, then the 
>inheritance should be suspect.

Except that, if you tell people that the prefix on the name tells the
type of the variable, they may believe you. If they do, in the case
of my example, they might well say "Oh, the prefix says that's a Stall."
and merrily proceed to locate the Stall class and begin working with
it. If they are not intimately familiar with the design of my code
( which they may not be, work assignments tend to be handed out based
on who is available rather than who is most familiar with a given bit
of code ), they may assume they can trust the prefix to be right and
skip checking the prototype, the class heirarchy and the like and go
right to the class that the variable *says* it is rather than finding
out what it *really* can be. The end result will be, at the very best,
a simple failure of their changes to work. At worst they'll have a
16 megabyte core dump on their hands.

>Why never a Stall?  If Stall's interface is present in any of its derived
>classes, Stall calls should be resolved.

Simple: Stall is merely the base class, and objects of it are *only* created
during program initialization as a bookkeeping device to keep track of
information while the program determines the actual current status of the
shower stall the Stall object represents.

Once you get into the subclasses, you get serious behavior differences.
For instance, Stall objects do not respond to changes in the physical stall
they represent. The routines are there, but they merely return. Each
subclass implements different behavior to a different set of changes, as
appropriate.

>True enough, but I think that new OOP programmers should drill it into
>their heads that references==pointers as far as polymorphism goes (and
>in other ways too).  Polymorphism has to change the way that you understand
>code.  We are not in Kansas any more. 

Assuming they check the prototype and then check the class heirarchy to
determine that they are dealing with a polymorphic type. As I said, this
conflicts with HN's theory that the prefix of the variable name itself
accurately reflects the actual type of the variable. This is exactly the
same situation as I run into with comments. Accurate comments are a
blessing, but the only thing worse than no comments at all is lots of
comments that don't reflect the actual code. If you have no comments at
all you automatically know you need to read the code, but if you have
lots of comments that are wrong but that you are told you can believe,
you may make the mistake of believing them at the wrong time and wind up
wasting two weeks wondering why your changes keep breaking the code when
according to the comments they shouldn't.

Yes a good programmer should check first. In an ideal world, all programmers
will. In the real world, though, somebody who's never seen the code before
gets told to make a major change to it and have it ready for release by
Thursday, and they've already got 4 other high-priority projects they need
to get finished, and checks to make sure what you are told is true really
is true sometimes get skipped. My experience is that every single time
that happens I get bit by it, so I tend to avoid things that would increase
the number of places that could happen.

--
Todd Knarr : tknarr@xmission.com      |  finger for PGP public key
                                      |  Member, USENET Cabal

Seriously, I don't want to die just yet.  I don't care how
good-looking they are, I! don't! want! to! die!"
                                        -- Megazone ( UF1 )