Here’s one example of why it makes sense to seal a class. It seems to be a comment on performance, but in fact the issue is much larger:
Why didn’t we fix ArrayList while we were at it? Ugh… we can’t. If we "fixed it" we would break existing applications. Because the class isn’t sealed it’s not possible for us to change the virtualness of the key functions involved so we have to live with that mistake.
Since the linked post discusses performance it might be easy to conclude that sealing the class is a kludge to fix performance problems in virtual methods. But in fact changing a method from virtual to non-virtual is changing the class’s contract, and virtual vs. non-virtual affects polymorphism, not just performance. In short, sealing the class would have had positive benefits in terms of encapsulation in this case.
{ 2 } Comments
This seems to be an argument for better design. They started with a crappy design and now they are saying they cannot fix it and are blaming "sealed classes" for poor design.
Sealed classes just make classes less useful. Do you want code to be reused or not?
So now .Net has a useful array list and a fast one.
"In short, sealing the class would have had positive benefits in terms of encapsulation in this case." but you end up with a class that is less useful
Brad, it sounds as though you missed the point altogether. For starters, they’re not blaming sealed classes for the design.
*Any* public method is part of your class’s contract. Altering the method in any way has potential effects on people who used an earlier version of the class. How you choose to write the class dictates to users what they can and cannot do with the class, whether or not it is sealed. So let’s get away from empty rhetoric about "sealed classes are just less useful"; there’s a lot of ways to write a useless class, and a well-designed sealed class is going to be a lot more useful than a poorly-designed unsealed class. Blanket assertions that sealed=less useful, to me, are symptomatic of an obsession with inheritance which seems to be common in the Delphi world.
Changing a virtual method in a non-sealed class to non-virtual violates the public contract you published when you first released the class. You can’t do it without breaking code. It’s like deleting a public member.
Now, I’m well aware that those programmers who never make mistakes don’t need refactoring tools, strong typing, assertions, contracts, debuggers, or encapsulation, but for those of us who do err from time to time certain protections do come in handy. It is useful to say, "I haven’t designed this class for inheritance, so you shouldn’t use it that way." Perhaps an analogy would come in handy. When I write a procedure which returns multiple values, I use the "out" declaration rather than "var." Both would work, but the former makes my intentions as the designer clear.
For those who would assert that not designing a class for inheritance inherantly makes it less useful, do you also design each and every one of your classes for composition, association, thread-safety, serialization, etc.? Can you accept that having a class that does one thing well just might be better than having something which attempts to be all classes to all people?
Post a Comment