On 07/12/2006, at 12:43 PM, Guyren Howe wrote:
Worth pointing out here that REALbasic has a superior mechanism:
the Event Handler. Define a method in the superclass, and call an
Event (that you define) in there. It makes the relationship between
superclass and subclass quite explicit (particularly absent an
Abstract declaration on methods), and places the superclass in
charge of the relationship rather than the subclass. Putting the
(single) superclass in charge of the relationship rather than the
(potentially many) subclasses is superior, briefly, because you're
more likely to be able to make changes in shared behavior that
aren't confounded by the when and how the subclasses override the
superclass, or when (if) the subclasses call back to the original
or other superclass support methods.
There have been numerous discussions about this on the NUG, going
back to posts by Andrew Barry (the original designer of REALbasic
and the originator of the Events paradigm) in the mid 90s, so I
won't go on at great length here.
But it deserves to be said: Events are unique to REALbasic. So if
you're reading advice about Object Oriented Programming, it won't
mention Events. Also, the REALbasic documentation is likely to lead
you to believe that Events are just for controls to propagate user
interface actions. Not so: Events are a general-purpose extension
mechanism, and except in some unusual cases, are simply superior to
method overriding.
huh?
I thought Events were a (partly) hack to get around the fact that
parent classes in the framework of RB, until 200x, didn't have
virtual methods so an alternate override mechanism was added to the
language ;-)
Maybe I've spent just too many years with other OO languages but I
really had trouble understanding this post and particularly how it
applied to a Factory situation.
I know you're a big fan of events, possibly the clearest post of
yours I have seen on the topic was
http://support.realsoftware.com/listarchives/realbasic-nug/2006-03/
msg00903.html
which I will take the liberty of quoting partly to save others
looking it up:
"I offer an example of how Events make for more easily maintained
code, and a discussion of why Events are clearer.
The example: you are creating an application with an entirely
custom user interface. All your windows are just dirty big
canvases, and you draw all your controls with custom classes.
You use method overriding. You create a MyControl class, give it an
abstract Paint method, and override this in your twenty-odd
different control subclasses, to do the actual drawing.
Now, OS X comes along, you want to do something fancier, you decide
that all your controls need a glowing backdrop and a water drop
effect. For whatever reason (this is just a hypothetical), you need
to draw the glow *before* you draw the control's details, and the
water-drop effect *after*.
You're screwed. You have to rewrite every single subclass. Each
subclass may or may not call the superclass's Paint method (they
probably didn't because it was empty), but in any event, that
doesn't give the superclass the opportunity to act both *before*
and *after* the subclass.
If you've used Events, so the superclass is calling a PaintEvent
that the subclasses use to do their stuff, you have no problem
whatever: draw the backdrop, call the event, draw the water drop
effect.
"
I do think you have a bit of a knee-jerk response to recommend Events
as a general solution and you tend to recommend them without
explaining how they are working differently.
My perspective, which may well be wrong, is:
Events reverse the normal order of polymorphism.
A parent class declares a new Event.
In the inheritance chain from that class, the HIGHEST subclass that
implements that event will have its event handler called. (For a
method, the LOWEST subclass overriding the method would be called.)
A common idiom is for a subclass that handles an event to ALSO
declare a New Event with the same name, and propagate the event
downwards by calling that event in its event handler.
This can look a bit confusing, looking like a recursive call but it
is not and if no lower class has an event handler for the new Event,
nothing will be invoked.
Events are extremely useful in the case where a superclass needs to:
a) intercept the subclass functionality
b) with the option of still calling down to that subclass (via a New
Event of the same name and calling it to "rethrow" the Event).
I suspect Event dispatching is most costly than method calls, because
rather than going to the method pointed to by a given object, its
event chain needs searching from the top down (this could be well-
optimised but I am not confident).
There is one big side-effect of your Event-based dispatching that you
don't mention, they mean the author of a subclass can never be sure
if they have completely replaced the parent class behaviour.
Overriding a method guarantees your implementation gets used (unless
a further subclass overrides it in turn). Implementing an Event
handler has no such guarantee.
As a further weakness, you have to inspect each and every class up
the inheritance hierarchy to see if they intercept the handler and
whether they rethrow the Event (just the fact that they declare a New
Event named blah is no guarantee that they also invoke it, you have
to look into their blah handler).
regards
Andy
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
