On 2002.07.07, Tom Sawyer <transami / transami.net> wrote:
> ha! that's funny, that's exactly what i was working towards! thanks for
> the help in that direction. actually though, i gave the example just to
> show you how much i was passing self. but i didn't give an explination
> --the reason i have to pass self is that the subrecords have actions
> too, as you can see in the action method. when one of those those
> actions is "hit upon" they SOMETIMES need to call customers display
> routine to finish up. i suppose i could pass a request back up to
> customer to take care of this. but that raises an interesting point and
> question: 

> is it good coding not to pass self?

The only place where I see passing self as being The Right Thing To Do
is in ZenAcct::ZenCustomer#display.

All of the others have a code smell.  Perhaps it's asking for
a refactoring along the lines of the Command pattern ...

It really appears to me that you've spent too much time in the
C/C++ world (probably Win32/MFC programming) where you are so
used to the paradigm of message pumps (event queues, etc.) and
so you naturally design the interfaces between classes as such.
In other words, when all you have is a hammer, everything looks
like a nail.

Also, it seems you're feeling Multiple Inheritance envy in Ruby
whereas you had it in C++ -- you don't have to envy, you have
it in Ruby (kinda) too.  They're called Mixins.

I'm not certain why ZenCustomer directly inherits from ZenRecord,
because I don't know what ZenRecord really offers.  However,
the ZenAddress .. ZenURL smell like they want to be "member
variables" of the ZenCustomer class the way you coded it.  If
I were coding this, I'd say that a ZenCustomer probably inherits
things like a ZenAddress, ZenPhone, etc.  Is there a reason why
those elements need to be classes, and can't simply be mixed-in
to a ZenCustomer?

(Ah, you'll probably say: because in your persistence implementation,
they're seperate entities and therefore need to be seperate classes ...
which sounds like you're letting your persistence implementation drive
the design, which is bad.  The design should always drive the
implementation details, including the persistence mechanism.)

-- Dossy

-- 
Dossy Shiobara                       mail: dossy / panoptic.com 
Panoptic Computer Network             web: http://www.panoptic.com/ 
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)