application of sealed keyword

[Zeng]

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

Thanks!

[Frank Oquendo]

Zeng wrote:

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

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)

[William Ryan]

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/de...tml/copybr.asp
"Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...

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

Thanks!

[Zeng]

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.

"William Ryan" <do********@nospam.comcast.net> wrote in message
news:Oq**************@TK2MSFTNGP09.phx.gbl...

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/de...tml/copybr.asp "Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...

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

Thanks!

[William Ryan]

If the class by design had static members, mixing them could cause problems.
Think about Brushes for instance....
"Zeng" <zz*@nonospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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.
"William Ryan" <do********@nospam.comcast.net> wrote in message
news:Oq**************@TK2MSFTNGP09.phx.gbl...

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/de...tml/copybr.asp

"Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...

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

Thanks!

[Zeng]

Would you please be more specific? I'm not quite following your example.
Thanks!
"William Ryan" <do********@nospam.comcast.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

If the class by design had static members, mixing them could cause problems. Think about Brushes for instance....
"Zeng" <zz*@nonospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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.

"William Ryan" <do********@nospam.comcast.net> wrote in message
news:Oq**************@TK2MSFTNGP09.phx.gbl...

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/de...tml/copybr.asp "Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...
>
> Would somebody know when we should seal a class? Shouldn't all

classes be

> open up for inheritance?
>
> Thanks!
>
>

[Zeng]

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

"William Ryan" <do********@nospam.comcast.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

If the class by design had static members, mixing them could cause problems. Think about Brushes for instance....
"Zeng" <zz*@nonospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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.

"William Ryan" <do********@nospam.comcast.net> wrote in message
news:Oq**************@TK2MSFTNGP09.phx.gbl...

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/de...tml/copybr.asp "Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...
>
> Would somebody know when we should seal a class? Shouldn't all

classes be

> open up for inheritance?
>
> Thanks!
>
>

[William Ryan]

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.
"Zeng" <zz*@nonospam.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

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

"William Ryan" <do********@nospam.comcast.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

If the class by design had static members, mixing them could cause problems.

Think about Brushes for instance....
"Zeng" <zz*@nonospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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.

"William Ryan" <do********@nospam.comcast.net> wrote in message
news:Oq**************@TK2MSFTNGP09.phx.gbl...
> 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/de...tml/copybr.asp

> "Zeng" <zz*@nonospam.com> wrote in message
> news:OO**************@TK2MSFTNGP12.phx.gbl...
> >
> > Would somebody know when we should seal a class? Shouldn't all classes be
> > open up for inheritance?
> >
> > Thanks!
> >
> >
>
>

[Sherif ElMetainy]

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

"Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...

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

Thanks!

[Zeng]

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!

"Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message
news:OI**************@tk2msftngp13.phx.gbl...

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

"Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...

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

Thanks!

[Daniel O'Connell]

"Zeng" <zz*@nonospam.com> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl...

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
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.
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.


Thanks!

"Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message
news:OI**************@tk2msftngp13.phx.gbl...

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

"Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...

Would somebody know when we should seal a class? Shouldn't all classes

be open up for inheritance?

Thanks!

[Zeng]

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!

"Daniel O'Connell" <[e-mail]> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...

"Zeng" <zz*@nonospam.com> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl...

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

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.

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.

Thanks!

"Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message
news:OI**************@tk2msftngp13.phx.gbl...

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

"Zeng" <zz*@nonospam.com> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...
>
> Would somebody know when we should seal a class? Shouldn't all

classes be

> open up for inheritance?
>
> Thanks!
>
>

[Daniel O'Connell]

"Zeng" <zz*@nonospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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. 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.

Thanks!

"Daniel O'Connell" <[e-mail]> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...

"Zeng" <zz*@nonospam.com> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl...

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

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.

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.

Thanks!

"Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in

message news:OI**************@tk2msftngp13.phx.gbl...
> 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
>
>
>
> "Zeng" <zz*@nonospam.com> wrote in message
> news:OO**************@TK2MSFTNGP12.phx.gbl...
> >
> > Would somebody know when we should seal a class? Shouldn't all classes be
> > open up for inheritance?
> >
> > Thanks!
> >
> >
>
>

[Zeng]

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.
"Daniel O'Connell" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Zeng" <zz*@nonospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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.

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.

Thanks!

"Daniel O'Connell" <[e-mail]> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...

"Zeng" <zz*@nonospam.com> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl...
> 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
>

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.

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.
>
> Thanks!
>
> "Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message > news:OI**************@tk2msftngp13.phx.gbl...
> > 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
> >
> >
> >
> > "Zeng" <zz*@nonospam.com> wrote in message
> > news:OO**************@TK2MSFTNGP12.phx.gbl...
> > >
> > > Would somebody know when we should seal a class? Shouldn't all

classes

> be
> > > open up for inheritance?
> > >
> > > Thanks!
> > >
> > >
> >
> >
>
>

[Daniel O'Connell]

"Zeng" <zz*@nonospam.com> wrote in message
news:eB*************@tk2msftngp13.phx.gbl...

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.
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).
"Daniel O'Connell" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Zeng" <zz*@nonospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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.

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.

Thanks!

"Daniel O'Connell" <[e-mail]> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...
>
> "Zeng" <zz*@nonospam.com> wrote in message
> news:eG**************@TK2MSFTNGP12.phx.gbl...
> > 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
> >
>
> 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.
>
> 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.
>
>
> >
> > Thanks!
> >
> > "Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in

message

> > news:OI**************@tk2msftngp13.phx.gbl...
> > > 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
> > >
> > >
> > >
> > > "Zeng" <zz*@nonospam.com> wrote in message
> > > news:OO**************@TK2MSFTNGP12.phx.gbl...
> > > >
> > > > Would somebody know when we should seal a class? Shouldn't all
classes
> > be
> > > > open up for inheritance?
> > > >
> > > > Thanks!
> > > >
> > > >
> > >
> > >
> >
> >
>
>