Jack Jackson wrote :
"Not at all. The inherited form may have no interest in some of the events
handled by the base class - it wants the base class event handling to occur.
To arbitrarily not service any event handlers in the base class just because
a form is inherited seems like madness to me."
I think you have not quite understood my comments. We probably agree more
than you think : I would say any inherited form that for some reason doesn't
use any major part of its "parent's" functionality and events is poor
design. I bet you, like me, have ended up re-designing forms so that a first
prototype form, from which other forms have inherited, ends up being
"forked" so that it becomes two form classes : one of which is the core
functionality, objects, and events which all inherited forms use, and
another which adds some additional features that all its descendants will
use. I've even used (gasp) the Templates facility once in a while to avoid
doing this.
"Usually when you use inheritance you are trading some level of obfuscation
(by hiding code in various levels of inheritance) for not duplicating code.
I think by careful documentation and thought about what functionality
belongs in what class the result is much better than not using inheritance."
Here we are in complete agreement
And very eloquently stated, I might
add ! My objection is not to the core idea of event broadcasting which is
one of the most wonderful things in .NET, but to the sticky wickets I have
gotten into using inherited forms. I would argue that inherited forms are
appropriate in some cases (top-down design scenarios, particularly), and
very potentially deadly in other scenarios (like prototyping).
"If inherited classes need to remove controls from the base class, then I
suggest that those controls should not be in the base class.
If you wire up an event in a base class, then all inherited classes should
use that event as defined in the base class.
If you want inherited classes to be able to optionally use the event
behavior of the base class, then you need to wire up the event in a way that
allows the inherited classes to make that choice. The way I do this is to
copy what the .NET framework does.
Suppose my base class has an Edit button. In the base class I have a
handler for the Edit button Click event that calls a "Protected Overridable
Sub OnEditClick()" method. In that method is the base class code to handle
the event. If an inherited class wants different behavior, it overrides the
method."
Your comments are eloquent and interesting, and appreciated. The last time I
tried (in C#) to implement this by making the procedure in the base class
public virtual, and the implementation in the inheriting class public
override , I was able to avoid calling the base class event, but my button
event handler was called twice for unknown reasons ! However, I was not
using the level of indirection you have described in your example (for which
I do not know off the top of my head the equivalent in C#) : perhaps therein
lies the rub.
It is good to continually re-evaluate what one assumes ! But I remain
convinced that inherited forms in any circumstance where usage is not 100%
consistent with the base class they inherit from ... and only ADDS
additional controls and functionality ... is a sticky wicket and liable to
distract me in real world development.
thanks, Bill