on 3/10/06 12:45 AM, Guyren Howe at [EMAIL PROTECTED] wrote: > Very well. I offer an example of how Events make for more easily > maintained code, and a discussion of why Events are clearer. > > The example: you are creating an application with an entirely custom > user interface. All your windows are just dirty big canvases, and you > draw all your controls with custom classes. > > You use method overriding. You create a MyControl class, give it an > abstract Paint method, and override this in your twenty-odd different > control subclasses, to do the actual drawing. > > Now, OS X comes along, you want to do something fancier, you decide > that all your controls need a glowing backdrop and a water drop > effect. For whatever reason (this is just a hypothetical), you need > to draw the glow *before* you draw the control's details, and the > water-drop effect *after*. > > You're screwed. You have to rewrite every single subclass. Each > subclass may or may not call the superclass's Paint method (they > probably didn't because it was empty), but in any event, that doesn't > give the superclass the opportunity to act both *before* and *after* > the subclass. > > If you've used Events, so the superclass is calling a PaintEvent that > the subclasses use to do their stuff, you have no problem whatever: > draw the backdrop, call the event, draw the water drop effect.
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 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). 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. 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>
