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::Init and Control::Load events that people end up doing this with. I've tried to explain it on DOTNET mailing lists 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, we should 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 On method that inheriting classes can override.

[Drew's Blog]

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 pattern is great for dealing with other objects, but why do it up the inheritance chain?