Sealed is Good? Well...
Ingo's unquestionably a brilliant guy. But I find myself disagreeing with
the generalization that "Sealed" is good.
The scenario Ingo outlines is an illustration of why sealed may be a necessary evil in some instances. Still, there are alternate cases where sealed is not necessary and probably just evil. (Sure, evil being an overly strong characterization on both counts.)
In the case of ImageList and other classes wrapping native api classes, the threat of breakage makes sealed a justifiable if conservative decision. In the case of
System.Web.UI.CssStyleCollection that I was griping about last week, you're not wrapping a non-.NET class. Breakage is only an issue if this class itself changes in future versions of System.Web--but if that's the only consideration, what's the argument for not sealing System.Object? (</hyperbole>)
Other controls compose or nest CssStyleCollection. Great. How does deriving from it impact those classes? What's more, how would creating an instance of the class impact other parts of the framework? My contention is there isn't external impact and that sealing this class (and hiding its instance constructor as internal) is just heavy handed or way too conservative as a design decision. It makes the class effectively useless to developers outside the .NET team--which matters if you want to try and create a default experience for control users.
Is it the end of the world? Not hardly, but there are other lurking classes (the default ASP.NET controls seem to leverage a number of them) with similar issues and I just like to see future versions of the framework take these kinds issues into consideration. Sealed isn't bad, sealed isn't good. It just packs a wallop and should be used very judiciously.