Ingo says that “sealed” is good. Is it?

Ingo says that "sealed" classes are a good thing and goes great lengths to explain why he thinks so in this article.

Now, I do have a little problem with his conclusion (which I still partially share, because I do write sealed classes every once in a while, but for a slightly different reason, see below) because the example he's using isn't really fitting the problem and he actually makes some assumptions about the ImageList class that aren't accurate in this context. 

First off, the property ImageList.Images isn't virtual and therefore cannot be overridden, at all. So that by itself is no reason to make the class sealed. The property has been introduced by the class, the class designer chose not to make it virtual. Can't be overriden, done. The same is true for all other properties except Container and Site, which are inherited from System.ComponentModel.Component. I fail to see anything on the ImageList class (not even a method) that really justifies the lockup using sealed considering the current version of the Framework. The bad that sealed does here is that I can't create a wrapper around the ImageList that simplifies setting up such a list in my specific environment.

Using sealed on a class is a very brutal thing to do. A more gentle way of using the sealed keyword is to say [void sealed override myMethod() { }], which essentially says: "Within my own class space I am using inheritance for this method, but since outsiders don't know what I am doing I won't let them override the behavior from here downwards in the class hierarchy." That doesn't affect the inheritability of the entire class and hence doesn't adversely affect the ability to wrap the existing functionality. 

Now ... is sealed on a class just plain evil? There are two answers:

• Yes. The keyword sealed on a class usually doesn't have much or any of a technical justification in the "here and now" version of a class library.
• 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.