Thursday, July 24, 2003

Sealed is Good

I’m constantly hearing from people, “Why would Microsoft do that?”
Or sometimes it takes the form of, “Why didn’t Microsoft
do that?” Almost invariably, this is because people are examining the situation
from the narrow perspective of their own problem domain. “Hey, I need something
that knows how to connect to any database and hide all the differences, and I’ve
figured out how to do it for my problem domain where I control all the variables.
So Microsoft should be able to do it for everyone.”

Well, the lessons of the last two decades have shown us that solving a problem generally
is much, much harder than solving it for one specific case. Or, to put it another
way, things are almost never as straightforward as they first appear. Along those
lines, Ingo has posted an article that
is an excellent example of this precept.


  1. No, I stand by what I said. Sealed sucks. At the very least, it does in the area where Ingo was trying to convince me it was a good thing.

  2. Hmm, I'll have to think about the implications of unsealing the class. The biggest issue is generally that your class can now be used anywhere the base class is expected. So if Microsoft has code written against the base, and you hurl your own class in there, it could break things. So it may not so much be them protecting you from yourself as them protecting themselves from you.

    Inheritance hierarchies where the various pieces are written by different developers are super scary. We talk about encapsulation in OO as a good thing - well inheritance busts that into tiny pieces because you're modifying the way the base class behaves, and it's modifying the way you behave.

    Does this mean it doesn't suck for you? Of course not - it clearly sucks for you. I'm just pointing out that many people underestimate the dirtyness of what often looks like a clean abstraction, or the complexity of what looks like a simple problem. How many times have you started down a path only to hit a wall. "Damn! I didn't think of that" is probably the one phrase I've said more than any other in my career. With the possibly exception of "Work, you *expletive deleted*!"

  3. Yeah, I hear you. It's just that Microsoft isn't going to be hurt if I screw up a derived class - they're not selling my software, I am. If an app using one of my handy-dandy, new-and-improved ImageListEx classes dies horribly, taking the OS, hard drive, and the goldfish in the tank next door with it, it's will be blamed on the app that was running when everything went wonky, not the .NET Framework. As it should be - it will have been due to me being a big dumb-head.
    I guess what I'm saying is: test it in the scenarios you can think of (or find the use cases are willing to stand by), draw a line, and say "There you go. We'll cover you up to this point. If you cross this line, you're on your own."
    Incidentally, I actually can think of one or two scenarios where sealed makes sense. I can see a use for sealing security-related classes, for instance. But I can't think of many others.

  4. So, here's the counter to that argument: Microsoft *is* going to get called when the app goes down. If you've ever supported an application in production (you probably have) you know that the first thing users do is blame Microsoft. And then call them up and submit bugs. Which costs money, pain, and time.

    This worldview says that if it ain't sealed, you're supporting those that wish to override it. Which is an enormously weighty thing.

  5. Heh. My recollection is that their first reaction is to blame me. :)

    Seriously, though - my experiences have shown that it's often the other way around; I've often had clients griping to us about problems when it was in fact a driver or OS issue. I honestly can't recall a single time when one of our end users went to Microsoft first.

  6. So does that support or oppose my argument? :) What I mean by that is, won't Microsoft have the same perspective as you? That the users come to them first?

    Even if it's not true, they're certainly going to see things that way because they don't see the cases where people don't talk to them.

    I was thinking about your comments last night (*cough* I'm a nerd *cough*), and I harkened back to MFC. I was never a huge MFC programmer, but I remember that MFC shipped in source form. I have to think one of the reasons for this is that it just got to be too hard to design for black-box extension of a UI framework while maintaining efficiency. This is consistent with the law of leaky abstractions that I'm sure you've read. Certainly, it's consistent with my experiences around the shortcomings of OO as a reuse mechanism, *especially* wrt inheritance.

    Bottom line for me: designing a reusable class library is super hard. It's much easier with sealed, since it cuts out 90% of the weird cases that can screw you. Therefore sealed is a good thing to be *able* to use.

    I yeild the remainder of my time to the gentlebeing from mindspring. ;)