Stupid C# Tricks – Sealed Classes
- March 21st, 2010
- Posted in General Nerdery
- By AMB
- Write comment
So as platform-driven languages go, C# isn’t a bad one. We’ve had some good times together, and I’m rather fond of the bloated, lumbering behemoth. But there are a few things about it which drive me absolutely insane. One of these is sealed classes.
Now the conventional wisdom is that sealing classes improves performance and security. First of all, if a sealed class increases performance (which it doesn’t in all cases), then those gains are absolutely negligible. Relying on sealed classes to get your app to meet benchmark requirements is a little like entering a horse in the Kentucky Derby, and then relying on giving him a good shave to make him win. Even if the minor weight loss DOES make him a bit faster, it’s not going to be enough to win. Plus now you have an angry, naked horse on your hands.
Okay, so that analogy went kind of a weird place. But I hope my point is clear: sealed classes don’t provide good enough performance boosts to really make a difference. If the kind of operation-shaving that sealed classes sometimes result in is really your last resort for optimization, then you may have a bigger problem on your hands than you think.
As for the security argument, well, I just don’t buy it. It seems that people think that a lack of inheritance is somehow a security feature, but I just don’t see how. If not allowing your C# code to be overridden or reused by other people is really key to your “security” methodology, then you better hope that none of your customers are smart enough to use Reflector. I mean, this security argument is really so stupid that I can’t help but think that I must be constructing a straw man. Alas, a quick Google search seems to indicate that sealing classes is widely understood to be “good security.”
Of course, none of this would be that bad if it was just a smattering of C# developers who went around sealing their classes. The problem is that a lot of very useful classes in the platform itself are sealed. I recently found another such class when I tried to override the Console class. Apparently the C# team at Microsoft has decided that no one will ever need, want, or get to override Console. Which would be fine, except that I both needed and wanted to override Console.
Why, you ask? Well, to be fair, it was for a gonzo code joke that probably would have amused only me. But the fact of the matter is, I won’t get a chance to find out if it’s as funny as I thought it would be, because .NET won’t let me override the Console class.
So that’s the rant. Sealing classes is both useless and annoying, doubly so when it’s done to basic platform classes. What’s more, I’ve not seen a single good argument in defense of the practice.
Though just watch, a few weeks from now, we’ll see someone flogging sealed classes on the grounds that it protects the world from dubiously funny jokes by bored twenty-somethings.

Summary: Conventional Wisdom and Smart are not always the same thing.
Or rather: StackOverflow and Wisdom are generally mutually exclusive
P.S.- Think of all the awesome google SEO juice you’ll get by having “naked horse” in your post!
Agreed on all points. StackOverflow is typically where I go if I find myself in need of code that doesn’t work and would be a bad idea, even if it did.
That is, of course, except for the 1 time in 20 when it solves my problem exactly and elegantly.
Still, the whole site is pretty much an exercise in Signal-to-Noise problems.
P.S: I’m actually receiving noticeable amounts of traffic on “naked horse” and “shaved horse” types of terms. Did I miss something on the inter-web-tubes about a naked equine?
It seems like Daniel Radcliffe was in something like that. You know, the actor that portrayed Harry Potter. There, that should help out your search results.
Oh, that’s right. He was in a production of Equis. Well, I fear people coming here looking for pictures of Mr. Radcliffe’s er, ahem, “wand” will be sore disappointed.
At the 2010 #railsconf, @dhh communicated the same sentiment regarding ruby monkey patching.
Ultimately, treating developers like retarded children is neither practical nor necessary.
Alas, it has taken a decade with the Java and .NET behemoths to learn this the hard way.
Agreed. Unfortunately, even after a decade, they still have a lot of learning to do.
Simply put: there’s no way for a language to “protect” bad developers from themselves and any “protections” one does put in place are just going to annoy the good developers and make their lives more difficult.
You are missing the point, consider the following function
SendQueryToService(QueryObject query)
Where a query object represents a query in some data storage agnostic language.
Now as a serious developer you should know by now that function is not just a
Signature and details in regards to the expected uses
It is a contract… an unconditional promise!!!
What is that function (should) tell you?
It tells you that it can process ALL QueryObjects in the entire universe
Those who are defined and those which not yet.
So you think to yourself, ok I will derive my own QueryObject and send it to the service
But you forget that there is a another side to the story….the query processor
Which is out of your control, and does not necessarily knows how to use your implementation
And the next thing after you sends your query to the service 200
Power stations at you country shut down….
Consider this to be a “distributed Liskov substitution principle” Violation.
So bottom line, design for inheritance or prevent it!
(Better prevent it; inheritance is just a side effect of OOP,
Polymorphism is what we want)