Don’t Seal That Door

January 11, 2008

tags: ,

I’ve been going over this week’s updates, and ran across this post in CodeBetter, that talks about why classes should be sealed by default, only to be unsealed by the ‘unsealed’ keyword.

I couldn’t disagree more. I think that you need a hell of a good reason to seal a class, so claiming that most classes should be sealed is a bit seems outrageous to me. I believe it’s absurd to prevent extensibility for your classes, and if classes are sealed by default, the result will be, obviously, a lot more sealed classes around. After all, unless you plan your class as some sort of base-class, you probably won’t even think about adding that ‘unsealed’ word. And you know that at some point it will make absolute sense for you to extend a class in a way the creator did not consider, and you will be rather screwed.

The reasons to leave a class sealed, taken from the great CLR via C# book, seem to pale in comparison with this issue. I think that is a very rare case in which your performance bottleneck is unsealed classes, and in these special circumstances you’ll probably consider this beforehand.

About security and predictability – well, I don’t agree that you have to baby-sit inheritors. It is a good idea to create a design that supports correct extensibility points, but if you have to default to anything, default to unsealed. It can be impossible for you to predict all the cases in which your class is used, and if the inheritor breaks anything, well, that’s his problem. If it were up to me, I would make all the methods virtual by default as well (as it is in Java). Quite often it happened to me that I really wanted to override protected methods which were not marked as virtual, and I had to hack around that.

About versioning, well, again, the case in which you would want to change a class to be sealed seems extremely rare to me, at best.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



  1. Sasha GoldshteinJanuary 11, 2008 ב 19:22

    Well, since you can’t really extend a class if it hasn’t been written with extensibility in mind (because methods are not virtual by default), does it really matter? Whenever you’re writing a true extensibility point you probably know about it and you can resort to that “unsealed” keyword (BTW, it doesn’t rock my boat either).

    Besides, I frankly don’t understand the religious wars about stuff like that – if you’re so desperate to extend a class, there are means of doing that other than inheritance.

  2. doronyJanuary 11, 2008 ב 21:14

    I do feel that methods should be virtual by default as well, but even when they’re not – inheritance can be the most natural and “correct” way to extend a class (although features like extension methods can also be very useful sometimes).

    I don’t think that you should ever be “desperate” to extend a class. When you’re using an object oriented language, you should never get to that point.