on 3/10/06 9:19 AM, Guyren Howe at [EMAIL PROTECTED] wrote: > 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.
I guess I don't understand why if the event model has two methods (Paint and the PaintEvent) that the override model doesn't have the same or more. The only thing that makes your event model work is that it is split into two parts. > >> 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. 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. > 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. 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. > 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. 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. Chris _______________________________________________ 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>
