application of sealed keyword

  • Thread starter Thread starter Zeng
  • Start date Start date
Z

Zeng

Would somebody know when we should seal a class? Shouldn't all classes be
open up for inheritance?

Thanks!
 
Zeng said:
Would somebody know when we should seal a class? Shouldn't all
classes be open up for inheritance?
Click to expand...

That's the whole point: that decision is left to the designer.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
There are some things that you don't want inheritable. The main thing that
comes to mind is that i fyou don't have to worry about anyone inheriting
from your class, you can change virtual function invokes to non-virtual
invokes. May not sound like a big deal, but it can be. Granted, there
aren't a whole lot of instances for this, but there are enough for it to be
noteworthy. Another instance is when you may have all static members

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncfhowto/html/copybr.asp
 
Thanks for replying, I can see the first instance you pointed out, but the
second one..hm, if the guy next door wants to inherit my class which has all
staic members, then it would be up to him, there isn't a design issue there.
 
If the class by design had static members, mixing them could cause problems.
Think about Brushes for instance....
 
By the way, about the first design usage, you could just use the scope of
your class if you want to avoid calling virtual function; in addition, with
a good design, the override method of a derived class should always replace
the functionality of the one it overrides
 
Zeng:

You're right, you could. However, that's a lot of work when you could just
seal it. There's almost always a few ways to get somewhere, but some
routes are more direct.
 
Hello

First: If the sealed class is inheriting another class, using the sealed
keyword either in the method or class declaration make the CLR convert all
calls from virtual to normal method calls, because the runtime knows that
this method and can't be overriden. This can improve performance.

Second. When the class designer knows that the overriding of his method can
affect the functionality of his class. For example a method that performs a
security check before making a call to another method. The inheritor of the
method can override the method and calling the other method directly without
the security check, so you may want to prevent anyone from doing that.

Third, if the class has only static fields and properties, it doesn't make
sense to inherit the class. So the class designer can choose to seal his
class to avoid confusion.

Best regards

Sherif
 
Thanks for responding, among the three, I could see the first one being a
good reason for sealed keyword.

For the second one, if security is checked inside a loose method like that,
I can just wrap the class (~ private inheritance in C++ ) and call directly
whatever method I want w/o going through the security checking method. It
sounds to me that a bigger design issue exists for the example you described

For the third, if someone wants to inherit my static-method-only class then
be it, no programmer should or would inherit a class that has nothing to be
inherited, and because there isn't a un-planned consequence, we shouldn't
have to force a policy on it.

Thanks!
 
Zeng said:
Thanks for responding, among the three, I could see the first one being a
good reason for sealed keyword.

For the second one, if security is checked inside a loose method like that,
I can just wrap the class (~ private inheritance in C++ ) and call directly
whatever method I want w/o going through the security checking method. It
sounds to me that a bigger design issue exists for the example you described
Click to expand...

Well, that is not quite true. In a sealed, inherited class, the secure
method would be protected, not accessible via a wrapper(atleast if there is
any decent security), however the security check should happen in the
method, declaritive security isn't too tough, this particular method locks
away functionality for little purpose.
For the third, if someone wants to inherit my static-method-only class then
be it, no programmer should or would inherit a class that has nothing to be
inherited, and because there isn't a un-planned consequence, we shouldn't
have to force a policy on it.
Click to expand...

Sealed is used here to make things clearer. In most cases purely static
classes are not instantiable as they only have private contsructors, the
sealed helps avoid people trying to needlessly inherit from it. Other times
a sealed class with members shoudl not be initalized by anyone other than
the system.
Sealed is an option, its not something to use constantly but the lack of it
is more dangerous and subtle than its existance.
 
I still don't see anything dangerous that we can avoid with sealed keyword
unless there is a bigger design issue that sealed keyword "seems" to help.
Would you be able to give me a more detailed description of the class and
with security-checking method(s) in your example. A security checking gets
put inside a method doesn't sound like a good idea to me as you can't ensure
that things that it protects cannot be accessed w/o going through it, and
why is it a protect method, shouldn't it be a private method? Protect and
private are different only to the derived classes and sealed class don't
have derived classes.

Thanks!
 
Zeng said:
I still don't see anything dangerous that we can avoid with sealed keyword
unless there is a bigger design issue that sealed keyword "seems" to help.
Would you be able to give me a more detailed description of the class and
with security-checking method(s) in your example. A security checking gets
put inside a method doesn't sound like a good idea to me as you can't ensure
that things that it protects cannot be accessed w/o going through it, and
why is it a protect method, shouldn't it be a private method? Protect and
private are different only to the derived classes and sealed class don't
have derived classes.
Click to expand...
Well, as I said, inherited class:

class Class1
{
protected virtual void MethodIMayWantToSecure() {};
}

class Class2 : Class1
{
//since its inherited(and hence protected), you either have to
//seal the method or the class to protect against security issues
protected override void MethodIMayWantToSecure() { };
}

Much security would ideally be declaritve, using attributes. There are some
security issues with unsealed classes sometimes, althought I can't remember
any of them right off the top of my head.

It really sits at the same level as the non-implicit virtuality. Methods in
C# are NOT virtual by default, you have to apply the virtual keyword. Some
argue that they should be because everything should be overriddable, however
that isn't always the case. Sometimes your override of a method should never
be overridden, sometimes you do not want another class masquerading as your
class, etc. I'm not saying these happen every day, but they are things that
happen sometimes. Not having the tools to manage that situation simply helps
to reduce the value and stability of the platform as a whole.
 
Along with the performance advantage that Sherif pointed out earlier, I
would think sealed should be done at method level, not as class level. It's
not natural (comparing with objects or concept in the real physical world)
to have some class declare itself as un-extendable, especially when all of
the benefits discussed so far are benefits per method. From my (relatively
limited) experience, any policy that is not natural in the object oriented
system will cause problems later on. All classes have potential to be
inherited in the future, the pure static class shouldn't be a class in the
first place, it's only a syntax that the language uses to allow users group
a bunch of methods.
 
Zeng said:
Along with the performance advantage that Sherif pointed out earlier, I
would think sealed should be done at method level, not as class level. It's
not natural (comparing with objects or concept in the real physical world)
to have some class declare itself as un-extendable, especially when all of
the benefits discussed so far are benefits per method. From my (relatively
limited) experience, any policy that is not natural in the object oriented
system will cause problems later on. All classes have potential to be
inherited in the future, the pure static class shouldn't be a class in the
first place, it's only a syntax that the language uses to allow users group
a bunch of methods.
Click to expand...
However, it IS a type. C# 2.0 offers static classes (public static class
Class, IIRC) that is implicitly sealed and can only contain static members.
Static methods are associated with a given type and always with a given
type, they cannot(and should not) be global.

As for per method and per class, that is strongly related to the situation.
The most common reason to place it on an object is when an object should
NEVER be anything but that exact object, usually for security or performance
reasons. Sometimes sealed is used, in the real world, because inheritance
just doesn't work with an object. It is an annoyance sometimes, but it is a
reality. Inheritance is not magic and is certainly not always easy. If you
don't have the time(or the ability) to get it to work safely, not allowing
inheritance is usually the better course. Allowing it could result in
security issues, application crashes, performance degredation, data loss,
etc. You will also find(and probably write) objects that just can not
designed to be inherited, or can only be inheritable with reduced
functionality, or safety, or whatever. that is just reality.

Also, sealed isn't the only way to stop inheritance(not providing a public
or protected constructor will do it), sealed just allows you to do it
without using static methods to instantiate your objects.

That said, you will likely find very few classes that are sealed, and
probably fewer yet that you actually want to derive from. Sealed is a tool,
just as operator overloading and implicit casts...something to use sparingly
when its needed. Removing any of those features would simply mean taking
away flexibility for no conceivable reason(outside of arguments for "purity"
or other such nonsense).
 
Back
Top