K
Kylin
any better reason ?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
J
Jon Skeet [C# MVP]
Kylin said:any better reason ?
Any better reason than what?
Use sealed when either you want to override a property/method but make
sure that it can't be further overridden, or when you want to make sure
that a class can't be derived from.
Y
Yunus Emre ALPÖZEN [MCAD.NET]
Suppose that you have something like this;
public abstract class anAbstractClass
{
public abstract void someMethod();
public abstract void anotherMethod();
}
public class FirstDerivativeClass : anAbstractClass
{
public sealed override void someMethod()
{
}
public override void anotherMethod()
{
}
}
public class SecondDerivativeClass : FirstDerivativeClass
{
public override void anotherMethod()
{
}
}
public sealed class ThirdDerivativeClass : SecondDerivativeClass
{
public override void anotherMethod()
{
}
}
Now you have an abstract class and two abstract methods. At
FirstDerivativeClass, you implement someMethod() and do not want to anybody
to override it. You define it as sealed method. At SecondDerivativeClass you
can not override someMethod() but can override anotherMethod. At
ThirdDerivativeClass you still can override anotherMethod. But you guarantee
that there can not be a fourth derivative class by defining that class as a
sealed. Is it clear?
public abstract class anAbstractClass
{
public abstract void someMethod();
public abstract void anotherMethod();
}
public class FirstDerivativeClass : anAbstractClass
{
public sealed override void someMethod()
{
}
public override void anotherMethod()
{
}
}
public class SecondDerivativeClass : FirstDerivativeClass
{
public override void anotherMethod()
{
}
}
public sealed class ThirdDerivativeClass : SecondDerivativeClass
{
public override void anotherMethod()
{
}
}
Now you have an abstract class and two abstract methods. At
FirstDerivativeClass, you implement someMethod() and do not want to anybody
to override it. You define it as sealed method. At SecondDerivativeClass you
can not override someMethod() but can override anotherMethod. At
ThirdDerivativeClass you still can override anotherMethod. But you guarantee
that there can not be a fourth derivative class by defining that class as a
sealed. Is it clear?
A
Alan Samet
As a general rule, I avoid sealing my classes. It seems that invariably
I'll want to add functionality to something at a later date. I'm not
even sure that I like the idea that methods and classes can be
nonvirtual. And I really don't like the fact that static members are
always final.
While I'm about to do some complaining about certain .NET things, I'm
going to introduce it by saying that I believe .NET is a great product
for something still in its first version. The guys at Microsoft did a
great job.
I sortof wish you could add functionality to (or replace members of)
existing classes in C# like you can in languages like Ruby. -- like
being able to add the Left/Right methods to the string class for the
scope of an application, or replacing the Substring function with
something that doesn't throw an exception when the Length parameter
exceeds past the end of the string.
I kicked the air a few times when I noticed how many members of the
ADO.NET namespaces were sealed -- members like SqlDataAdapter. If it
were not sealed, and say, the "Fill" method was marked as virtual, you
could easily write some great diagnostic tools.
For instance, say you wanted the ability to view all of the raw
datasets going to an application. All that would be necessary would be
to subclass the SqlDataAdapter class, override the Fill method with
something that would, say, raise an event with your data. Then write a
simple windows application that spawned a window with a datagrid
populated with that data every time Fill was called. Have that windows
application act as a Remoting Server for your application, and set the
application to be a Remoting Client. When you're done diagnosing,
simply remove your remoting configuration.
-Alan
I'll want to add functionality to something at a later date. I'm not
even sure that I like the idea that methods and classes can be
nonvirtual. And I really don't like the fact that static members are
always final.
While I'm about to do some complaining about certain .NET things, I'm
going to introduce it by saying that I believe .NET is a great product
for something still in its first version. The guys at Microsoft did a
great job.
I sortof wish you could add functionality to (or replace members of)
existing classes in C# like you can in languages like Ruby. -- like
being able to add the Left/Right methods to the string class for the
scope of an application, or replacing the Substring function with
something that doesn't throw an exception when the Length parameter
exceeds past the end of the string.
I kicked the air a few times when I noticed how many members of the
ADO.NET namespaces were sealed -- members like SqlDataAdapter. If it
were not sealed, and say, the "Fill" method was marked as virtual, you
could easily write some great diagnostic tools.
For instance, say you wanted the ability to view all of the raw
datasets going to an application. All that would be necessary would be
to subclass the SqlDataAdapter class, override the Fill method with
something that would, say, raise an event with your data. Then write a
simple windows application that spawned a window with a datagrid
populated with that data every time Fill was called. Have that windows
application act as a Remoting Server for your application, and set the
application to be a Remoting Client. When you're done diagnosing,
simply remove your remoting configuration.
-Alan
J
Jon Skeet [C# MVP]
Alan Samet said:As a general rule, I avoid sealing my classes. It seems that invariably
I'll want to add functionality to something at a later date. I'm not
even sure that I like the idea that methods and classes can be
nonvirtual.
Personally, I love it. Designing classes to be derived from properly is
a lot of work, and shouldn't be undertaken when it's not necessary. To
be honest, I wish classes were sealed by default.
And I really don't like the fact that static members are
always final.
Well, how would you expect polymorphism to work with them, seeing as
you can't invoke a static method on an instance anyway? Which static
method is invoked is a compile-time decision, so it doesn't make sense
for them to be virtual.
While I'm about to do some complaining about certain .NET things, I'm
going to introduce it by saying that I believe .NET is a great product
for something still in its first version. The guys at Microsoft did a
great job.
I sortof wish you could add functionality to (or replace members of)
existing classes in C# like you can in languages like Ruby. -- like
being able to add the Left/Right methods to the string class for the
scope of an application, or replacing the Substring function with
something that doesn't throw an exception when the Length parameter
exceeds past the end of the string.
Sounds dangerous to me - sounds like the kind of thing which could
easily introduce unwanted and possibly insecure behaviour. For
instance, I know that when I use a string I can call any method and it
won't change the contents of the string. If one piece of code could
change the implementation of string, all the rest of my code would have
to take that into account.
I kicked the air a few times when I noticed how many members of the
ADO.NET namespaces were sealed -- members like SqlDataAdapter. If it
were not sealed, and say, the "Fill" method was marked as virtual, you
could easily write some great diagnostic tools.
But then the situations in which Fill is called for you from other
methods would have to be documented, and would then be set in stone,
etc. Like I said, designing for derivation is time-consuming.
For instance, say you wanted the ability to view all of the raw
datasets going to an application. All that would be necessary would be
to subclass the SqlDataAdapter class, override the Fill method with
something that would, say, raise an event with your data. Then write a
simple windows application that spawned a window with a datagrid
populated with that data every time Fill was called. Have that windows
application act as a Remoting Server for your application, and set the
application to be a Remoting Client. When you're done diagnosing,
simply remove your remoting configuration.
I can see how it's useful in certain situations, but I think the
downsides outweigh the upsides in general. Of course, with a proper AOP
system in place, you could have the above without making Fill itself
virtual.
B
Bob Powell [MVP]
I wish classes were sealed by default
That goes completely against the grain of oop concepts. The whole idea of a
system that supports inheritance and polymorphism is to promote reusability.
Sealing a class is an architectural descision taken when a provider wants to
prohibit that process even when a potential consumer of the code sees a need
to derive from it. It's not one that should be taken lightly or left as a
default case because that would mean that many classes would leave the
factory floor with unintentional sealing in place. The sealed keyword must
be explicit because it's connotations are so far reacing.
Like Alan I think that the sealed state of many of the .NET classes are an
architectural nightmare that prohibits people from using classes that are so
deficient that they need overriding just to make sense of them.
--
Bob Powell [MVP]
Visual C#, System.Drawing
Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm
Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm
All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
That goes completely against the grain of oop concepts. The whole idea of a
system that supports inheritance and polymorphism is to promote reusability.
Sealing a class is an architectural descision taken when a provider wants to
prohibit that process even when a potential consumer of the code sees a need
to derive from it. It's not one that should be taken lightly or left as a
default case because that would mean that many classes would leave the
factory floor with unintentional sealing in place. The sealed keyword must
be explicit because it's connotations are so far reacing.
Like Alan I think that the sealed state of many of the .NET classes are an
architectural nightmare that prohibits people from using classes that are so
deficient that they need overriding just to make sense of them.
--
Bob Powell [MVP]
Visual C#, System.Drawing
Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm
Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm
All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
A
Alan Samet
-- snip --
I couldn't agree with you more on this.
On a side note, it looks as if Boo will provide a lot of the stuff that
I'd like to see in a .NET language:
http://en.wikipedia.org/wiki/Boo_programming_language
-Alan
[Alan Samet] For instance, say you wanted the ability to view all of the raw
datasets going to an application. All that would be necessary would be
to subclass the SqlDataAdapter class, override the Fill method with
something that would, say, raise an event with your data. Then write a
simple windows application that spawned a window with a datagrid
populated with that data every time Fill was called. Have that windows
application act as a Remoting Server for your application, and set the
application to be a Remoting Client. When you're done diagnosing,
simply remove your remoting configuration.
I can see how it's useful in certain situations, but I think the
downsides outweigh the upsides in general. Of course, with a proper AOP
system in place, you could have the above without making Fill itself
virtual.
I couldn't agree with you more on this.
On a side note, it looks as if Boo will provide a lot of the stuff that
I'd like to see in a .NET language:
http://en.wikipedia.org/wiki/Boo_programming_language
-Alan
J
Jeff Louie
Hi Bob.... Here is some info on what Jon is talking about.
http://portal.acm.org/citation.cfm?id=28702
Regards,
Jeff
http://portal.acm.org/citation.cfm?id=28702
Regards,
Jeff
A
Alan Pretre
Kylin said:any better reason ?
If a method (or a set of methods) provides a contract (explicit or de facto)
to a consumer that it will behave in a certain way, with certain
side-effects, and these results, then with inheritance the original method
loses the ability to make that guarantee when something else comes along and
inserts itself in its place. At this point all bets are off and the
original guarantee to the consumer is no longer valid. If the loss of this
guarantee would be of too great a consequence to the consumer then the class
designer can seal the class to prevent this situation.
-- Alan
J
Jon Skeet [C# MVP]
Bob Powell said:That goes completely against the grain of oop concepts.
Why? It wouldn't change what was possible at all - just the default.
The whole idea of a system that supports inheritance and polymorphism
is to promote reusability.
Well, that's certainly *part* of the idea, IMO. There's more to it than
just that, and I don't see why making things sealed by default would
cause problems there.
I very rarely derive from another of my classes which I haven't
explicitly considered suitable for derivation to start with. It creates
all kinds of headaches.
Sealing a class is an architectural descision taken when a provider wants to
prohibit that process even when a potential consumer of the code sees a need
to derive from it. It's not one that should be taken lightly or left as a
default case because that would mean that many classes would leave the
factory floor with unintentional sealing in place. The sealed keyword must
be explicit because it's connotations are so far reacing.
Whereas I see leaving things unsealed as having far reaching
implications.
Like Alan I think that the sealed state of many of the .NET classes are an
architectural nightmare that prohibits people from using classes that are so
deficient that they need overriding just to make sense of them.
Those are problems with the classes' design in other ways than being
sealed though. Deriving from a class to fix design flaws is hardly
elegant.