32
votes

I was just wondering, since the sealed keyword's existence indicates that it's the class author's decision as to whether other classes are allowed to inherit from it, why aren't classes sealed by default, with some keyword to mark them explicitly as extensible?

I know it's somewhat different, but access modifiers work this way. With the default being restrictive and fuller access only being granted with the insertion of a keyword.

There's a large chance that I haven't thought this through properly, though, so please be humane!

9
I would argue that, if you made classes sealed by default, then that means you should NOT be using an object-oriented language. - Jon Limjap
Too many times have I come across sealed classes within the .NET Framework that I wanted to inherit and override functionality in. Same thing goes with internal. - Chris Pietschmann
a language with objects and messages but not inheritance is not object-oriented, but merely object-based - Steven A. Lowe
@Chris: Of you're still unhappy about the sealed .NET Framework classes, you may find blogs.msdn.com/b/ericlippert/archive/2004/01/22/61803.aspx to be an interesting read. - Brian
From MSDN: To determine whether to seal a class, method, or property, you should generally consider the following two points: 1) The potential benefits that deriving classes might gain through the ability to customize your class. 2) The potential that deriving classes could modify your classes in such a way that they would no longer work correctly or as expected. . . My preference is that if it's no extra work for me as the author of a class to allow others to derive from it, I don't mark it sealed. But if it my class is not designed for derivation in some subtle way, seal it. - zumalifeguard

9 Answers

45
votes

I'd say it was just a mistake. I know many people (including myself) who believe that classes should indeed be sealed by default. There are at least a couple of people in the C# design team in that camp. The pendulum has swung somewhat away from inheritance since C# was first designed. (It has its place, of course, but I find myself using it relatively rarely.)

For what it's worth, that's not the only mistake along the lines of being too close to Java: personally I'd rather Equals and GetHashCode weren't in object, and that you needed specific Monitor instances for locking too...

33
votes

In my opinion there should be no default syntax, that way you always write explicitly what you want. This forces the coder to understand/think more.

If you want a class to be inheritable then you write

public extensible class MyClass

otherwise

public sealed class MyClass

BTW I think the same should go with access modifiers, disallow default access modifiers.

13
votes

Inheritance is a foundational principle of OO, so arguably, disallowing it by default wouldn't be intuitive.

4
votes

You could probably make just as many arguments in favor of sealed-by-default as you could against it. If it were the other way around, someone would be posting the opposite question.

3
votes

I can't recall having heard a rationale for the decision to have classes not sealed by default. However, there are certainly quite a few people who believe that C# should have been spec'ed to have sealed be the default:

http://codebetter.com/blogs/patricksmacchia/archive/2008/01/05/rambling-on-the-sealed-keyword.aspx

3
votes

sealed classes prevent inheritance and therefore are an OO abombination. see this rant for details ;-)

3
votes

80% of the features of Word go unused. 80% of classes don't get inherited from. In both cases, once in a while, someone comes along and wants to use or reuse a feature. Why should the original designer prohibit reuse? Let the reuser decide what they want to reuse.

3
votes

Merely deriving from an unsealed class doesn't change the class's behavior. The worst that can happen is that a new version of the base class will add a member with the same name as the deriving class (in which case there will just be a compiler warning saying you should use the new or override modifier) or the base class is sealed (which is a design no-no if the class has already been released into the wild). Arbitrary sublassing still complies with the Liskov Substitution Principle.

The reason that members are not overridable by default in C# is that because overriding a method can change the base class's behaviour in a way that the base class's author didn't anticipate. By making it explicitly abstract or virtual, it's saying that the author is aware that that it can change or is otherwise beyond their control and the author should have taken this into account.

-1
votes

For the same reason why objects are not private by default

or

to be consistent with the object analogue, which is objects are not private by default

Just guessing, coz at the end of the day it's a language's design decision and what the creators say is the canon material.