Why does the 'sealed' keyword exist in .Net?

Designing classes (or frameworks) to be extensible isn't trivial, and put simply inheritance is not the single principle of Object Oriented programming.

So sealed exists to allow the developer / designer to express and preserve those intentions. Sealing a class can also make their life easier by reducing the maintenance burden. It allows the original developer to control how the class (or framework) is extended, so they can make internal changes without worrying about breaking changes to others code.

One principle is that developers should seal any leaf classes by default. Then, when the developer creates an unsealed class intentionally, it forces them to think about extensibility.

Ref: Eric Lippert - Why Are So Many Of The Framework Classes Sealed?

Without digging too deeply, understand that Microsoft favors sealing a class when there are potential security, maintainability or backwards-compatibility issues that it will have to deal with downstream. For example, System.String is sealed for security and performance reasons.

In this particular case, you'd need to ask a Microsoft developer why they chose to seal that class. However, the architectural guidance literature I've been reading lately tends to favor an approach of "seal unless you know it will need to be extended." This literature tends to espouse using extension methods where possible. (I'm not saying I agree with it; I'm just saying that's what I've been reading lately.)

Even if the class weren't sealed, the properties in question might have been left not virtual, which would still leave you up the creek here.

In your specific scenario, I'd go with extension methods with your own unique names. It's about all you can do.

While I do agree that .NET probably seals too much, it's generally to protect the integrity of an ecosystem. When one of your top priorities is to keep your overall framework/API/runtime stable, and there are somewhat fragile interdependencies between classes, it may be safest to prevent people from overriding that behavior and inadvertently destabilizing core functionality.

Though again, I do tend to feel that the .NET team seals too many classes. Sealing can sometimes be simple laziness on the part of the developer because a proper class design would be too much work.

I would suggest that there is no good reason for sealing classes other than to protect the ignorant -err, I mean innocent. You know the old saying, "given them enough rope and they will hang themselves". Let them sway I say. Perhaps this is my C++ background, but I am quite comfortable knowing that I have the power to completely stuff things up if I am not diligent.

I tend to program by interface. The interfaces are of course public and any one is free to provide their own implementation that adheres to the contract expressed by the interface. My concrete classes that implement these interfaces tend to be a private concern and are marked internal and/or private. I don't feel that I need to seal such classes.

Where code reuse is desirable, I avoid reuse through inheritance, favouring composition and other techniques.

Sealing may also be valid on types that are considered plain-old-data types, but I'm not convinced wither way on this.

It depends, there are classes that are intended to be just instantiated (inheritance, if exists, is used just to simplify the implementation), other classes are intended to be inherited to provide a spesific implementation.

Sealed classes have some advantages:

• they don't have any virtual methods, so they don't have to worry about non-"exception- safe" implemented overriding methods.
• If a class is immutable it can preserve and guarantee the immutability.

Otherwise if you want to decorate a sealed class with "comfort" methods use the extension methods (C# 3.0).