On Mar 10, 2006, at 7:01 AM, Chris Little wrote:
I fail to see the difference. Since in the override example these
aren't
real controls the parent class has a method that calls the Paint
method.
You can do whatever pre/post drawing work you need there. That the
sub-classes don't call the parent class method is just bad coding.
Not
calling a parent's method because you know it doesn't do anything is
fragile.
In the example, the canvas, or some other part of your drawing
framework is calling Paint() on the MyControls. At some point, you're
calling into these objects from the outside, right?
Doesn't matter if the subclass is calling the superclass's method;
you still can't take an opportunity to act both before and after the
overridden method call.
In designing a drawing model like this I would have made pre/post
drawing
methods as well as an internal drawing method. The parent class
would have
a draw method that is the public interface (in other languages this
wouldn't
be overrideable).
So you're introducing all kinds of extra complexity you didn't
initially need originally, because you happened to anticipate that
you might need it later. Congratulations, but:
- foresight like that isn't universal in programming; and
- other folks in this thread have criticized Events for introducing
extra complexity. Makes me laugh. You can either try to anticipate
every way in which you might need to have opportunities to act as per
your example. Or you could just use Events, and add those
opportunities as you need them.
Events are no panacea. But they remove much of this need to
anticipate what you might want like this, along with the extra
complexity involved.
What I dislike about events is that if you have a class structure
more than
one level deep and a non-leaf class implements an event you don't
know that
it exists when making a leaf class.
It would certainly help if the IDE were to show things like this, if
you're discussing failing to be aware of an Event you might have
wanted to handle. You might also mean that you forgot to re-declare
and call the same Event when you handled it in your superclass, but
this isn't generally a big deal. Events being top-down, every time
you step up one in your inheritance chain, you're dealing with fewer
classes to modify.
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.
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>
