On Mar 10, 2006, at 9:22 AM, Chris Little wrote:
I'm just extending what you're doing with events. You split the
operation
into two parts, I split it into four anticipating future need. In
either
case it is easy to add it in later.
I don't think that split with overriding is nearly as easy to add in
later. To add an event, I add it, and call it at the appropriate
place. OTOH, if I'm using method overriding, and I want to split the
subclass's calls back to the super's Paint method into a before and
after, I have to do that in every subclass. That's the crucial point:
by putting the superclass in charge, we simplify maintenance.
I guess I meant both. If the IDE had a better class browser that
should you
which super class implemented what it would help. As well I find
it strange
that I have to think about future overriding when I implement an
event.
Actually, you don't. At least, not nearly so much. Adding and calling
an Event at a suitable place in the super's behavior is generally
easy. The reason you're doing it is because one or more subclasses
need to do something new and different at some point in the super's
behavior, so there's no way of getting around having to implement
each one of those custom behaviors per subclass.
With method overriding, you'll be editing those same subclasses,
you'll just miss the small step of adding the new Event.
But in the reverse situation, where the superclass needs to do
something new around what the subclass is doing, is *much* simpler
with an Event. You just do it, once, in one place. With Overriding,
you have to change potentially every subclass's code before you can
do that.
You can redeclare and call the same Event everywhere you think you
might need it. And if you didn't, in my experience, it's seldom much
work to go back and add it. When the superclass doesn't provide an
opportunity for the subclass to act, you have one superclass to
modify. When the subclasses don't provide the superclass with an
opportunity to act, you have n subclasses to modify. This very nicely
illustrates the advantage to Events.
If you design your method overrides in the same way as events it
isn't any
more complex.
If you're going to just fake up Events, which involves more work than
just adding and calling an Event, why not just add and call an Event?
What you're proposing is more work: you now have to have every
external method call over to an internal "Event" method, just in case
you might need to handle it in the subclass one day. With Events, I
can happily add them as and when I need them.
I think where someone sits on the event vs override debate depends
on what
language you started with. For me it C++ and it doesn't have
anything like
events (actually you end up creating messaging schemes to simulate
them
quite often). On the other hand C++ had more a more descriptive
syntax for
classes that lets the author more easily control what can be
overridden.
Clearly. And there are many features from other OOP languages I would
love to see in REALbasic (introspection, first-class classes,
delegates...). I'm not saying that REALbasic has the best OOP
features of any language. But what I *am* saying, and no-one has yet
provided a good counterexample, is that Events being lower-
maintenance and clearer, should be used for class extension. And
someone's experience in other OOP languages doesn't apply to whether
this is true, because no other language has this mechanism.
Guyren G Howe
guyren-at-relevantlogic.com
http://relevantlogic.com
REALbasic, PHP, Python programming
PostgreSQL, MySQL database design and consulting
Technical writing and training
_______________________________________________
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>
