Andy Smith's Blog

I would assume this is so that outside programmers can easily extend classes written by other people unless they have explicitly taken steps to stop them.

The sealed keyword has no performance penalty for not using it. The reason that virtual isn't the default is really only a performance consideration.

Using sealed as default would be option in the security design of .net

Using sealed normally has only value for classes used in communication between components or in scenarios where you want to be flexible to change the implementation of your class so that inherited class cannot rely on specific flow or state of a class. That is the reason why a lot of framework classes are sealed.

My $.02 is that it's it's a granularity issue. In terms of member methods, not making them virtual ensures that a subclass type exhibits the same behavior as their parent -- If B is a subclass of A, you know that the inherited members don't break the contract set out by A.

At the class level, however, you don't break a contract if you subclass B from A and add NEW members to the programmatic interface.

So from the client code perspective -- if I've got a B reference, I can use the additional, more specialized members but still know that "B is an A" for the inherited functionality. From the over-used analogy department... If I create an Auto type and give it a non-virtual Start() method for the engine, you can create a subclass Truck. Client code knows that Start() will always start the engine and can't have been overridden to turn on the CB Radio.

Or maybe I'm wrong. :)

Andy,

I have been toying with the same question while working on my C# Coding Standards document.

Its obvious that only methods/properties that have been tested for extensibility should be designated Virtual.

However, the correllary for a non-Sealed Class has different reprocussions. The only harm in leaving a class non-Sealed is if there is critical initialization in the constructor, since any derived class has the option to omit calling the base constructor. Otherwise, I see no harm in leaving the class unSealed.

However, when that class is a subclass, the Sealed designation becomes very important. There are numerous times when you want to break the inheritance chain for security or maintenance purposes.

So, as a result, I think the Sealed keyword is very important, but there is no useful way to apply a blanket rule to say "Always apply Sealed...".

non-virtual by default was a way to beat java in benchmarks.

Virtual methods are slower to invoke that NonVirtual ones.

It's just a example of Microsoft holding developers back while showing up competition with false performance

[/conspiracy]

I still wonder how I test for extensibilty. This argument is often raised when virtual by default is debated.

So do you:
1. Add virtual to the method.
2. Add override to the other method.
3. Run the app, see what happens or..?

I can't figure this out, for to test on this you must have an extension scenario. It's impossible to know and test on every scenario.

Why is it so bad to let me test on my scenario and decide it it works or not? I know my scenario better than anybody else, and I can see if it works or not.

But I really like to know how I should test for extension.

I like it the way it is.

Lexapro weight gain. Lexapro. Lexapro withdrawal.