Ingo did spake:
Sometimes you might want to implement custom ImageList controls and encounter the fact that the .NET Windows Forms ImageList is marked as sealed. Instead of crying foul here, let's have a look at some of the reasons for this decision.
My latest article "Sealed is Good" shows you ...
... the reason for sealing ImageList.
... the reason why this is a good thing.
... the reason why unsealing it wouldn't help you at all.
And finally, the reason why unsealing it would demand a complete rewrite of all of System.Windows.Forms.
Have fun!
Clemens later added:
No. The keyword sealed conveys a very clear message that the class designer reserves the right to change the class so dramatically in a future release of the product that you would be tremendously unhappy if you had derived from it to implement your own functionality, once that new version comes along. Sealed says: This is going to change in a big way.
I agree that sealing GUI classes for performance reasons is probably a good reason to break traditional OO designs. But I have some reservations on applying them on anything beyond special use case classes. This is mainly due to the fact that I have seen some strange code that was sealed when it should not have been. I don't think that a lot of .NET developers are aware that you can seal single virtual methods and they seal a entire class when they really should only be sealing some specific method that you don't want futzed with. In most cases the methods that need seeling are end points where components are connected. (otherwise, just call a method non virtual or private and be done with it)
However, I do have one big gripe. I did a large legacy database project last year with had some strange timestamps. No problem thought I, extend DateTime to have a few pretty properties that did magic behind the scenes to covert to standard windows datetime. Plus with inheritence, I can databind to both winforms and ASP.net with a really simple set of code like:
ParDateTime T = new ParDateTime();
T.ParDate = // Some magic to get this from the database.
T.Months.Add(Today.Minutes);
Calender1.DateTime = T;
Nice simple and self documenting (Par is the name of the application).
Of course DateTime was a sealed class which resulted in a more convoluted set of code. Sealing classes make it harder (and dirtier) to add functionality. This leads to my general rule on sealing.
Never Seal Business or Logic Classes. Sooner or later you will want to extend them. If your object model really has nasty magic that requires you to seal a class rather then risk anyone deriving it, you might want to re-examine your design.