_I can’t remember the last time I’ve been handed source code for a Form- or UserControl-derived class that didn’t include a handler for its own Load event. Why is this? Sadly, I know the reason… _[Shawn A. Van Ness’s Blog]
Some solid advice from Shawn. He explains the common WinForms scenario, but it really applies in any component inheritance scenario. For example with ASP.NET, it’s mainly the
Control::Loadevents that people end up doing this with. _place_holder;I’ve tried to __explain it_ on _DOTNET mailing lists_ _place_holder;on a couple of occasions, but I still see people doing it from time to time. As Shawn points out, it’s not really a serious problem, but it’s just not the best practice. With .NET, we’re living in an OO world, _place_holder;we should _place_holder;take advantage of it and prefer method overriding in these scenarios._
Oh… and on the flip side of the coin, whenever you’re designing a component, make sure and follow __the recommended design guideline_ of defining a protected virtual
Onmethod that inheriting classes can override._
I can’t agree more. I’ve always wondered why MS chose to implement so many samples this way. It just doesn’t make sense. The observer/delegate _place_holder;pattern is great for dealing with other objects, but why do it up the inheritance chain?