Overriding "OnXXX" versus adding event handler

  • Thread starter Thread starter Peter Duniho
  • Start date Start date
P

Peter Duniho

Okay, this has come up in the past but I haven't seen anything that I
would call a good, solid general rule.

The question applies more generally, but I'm going to ask in the context
of a Control. How does one decide whether to write an "override" method
to an event and when to simply add an event handler for that event?

For example, you can either write a new OnPaint override, or you can
register a delegate that the Control's base OnPaint method will execute.

My current thought is that when you are not inheriting from the base
class, you register a delegate (duh, since you obviously have no way to
override the method in that case), and when you are inheriting from the
base class, you override the method (the main reason here being that if
you're inheriting from the base class, you want your new functionality to
always work, rather than relying on your delegate remaining in the event
handler list).

In other words, override when you can, add an event handler if you can't.

Is it really as simple as that? Or are there other factors I should be
considering?

Many thanks in advance for the wisdom of those who have gone down this
road before me. :)

Pete
 
it's as simple as that!
it's also easier to maintain...

when you override a method, all the functionality is in an easy to find
place.
if you use delegate, you've got hard to track bug, where you got to run the
debugger to realize some forgotten event handler have some annoying code...

--
Regards,
Lloyd Dupont
NovaMind Software
Mind Mapping at its best
www.nova-mind.com
 
I can see one other reason to override, and that is sequence. If you
override the "On..." method, you have the choice of executing your code
either before or after the base class's code. If you use a delegate, it will
always execute after the base class "On..." code. Sometimes you may want to
do the former.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net
 
Peter

for the sake of discussion

I have impression that main point is dynamic control. As you might know
event handlers could be changed on the fly, though maybe not always very
easy. Overrides are declarative, so you can change them only if you
regenerate assembly. So, objects with events behave more naturally and are
more flexible, generally speaking.

Also, on the more general side, "always" for new functionality is not that
good if you consider how quickly everything changes. New functions become
obsolete very quickly. Ideally, any component should be easily changed to
new version. Events are better suited for this versioning as they are by
nature dynamic. Overrides are too "hard-coded" for this.

Also I saw one point about "easier" to maintain. I do not agree overrides
are easier to maintain. No specific arguments yet in addition to above, but
somehow doesn't seem valid to me.

If event structure is designed properly, I would rather stay with events -
always. Main argument - to maximize re-use and maintainability I prefer not
to touch base functionality and not to deal with component (black boxes)
internals - of course, if only I don't develop component itself. If there is
a need to modify base class functionality, first what comes to my mind is
"design deficiency". Either for base class or for my class. One such example
is TreeView, which inconsistently raises Click event - from my point of
view, of course.
 
Amongst other things, there's a fairly significant performance advantage to
overriding vs handling events. If you're authoring a subclass, overriding
should be your default approach. The events are mainly there to be used by
consumers of the control, not its subclasses.
 
Back
Top