Re: why use the 'sealed' ?
- From: Jon Skeet [C# MVP] <skeet@xxxxxxxxx>
- Date: Sun, 8 May 2005 21:32:31 +0100
Alan Samet <alansamet@xxxxxxxxx> wrote:
> 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.
--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.
- Follow-Ups:
- Re: why use the 'sealed' ?
- From: Alan Samet
- Re: why use the 'sealed' ?
- From: Bob Powell [MVP]
- Re: why use the 'sealed' ?
- References:
- why use the 'sealed' ?
- From: Kylin
- Re: why use the 'sealed' ?
- From: Alan Samet
- why use the 'sealed' ?
- Prev by Date: TextBox + colour
- Next by Date: Re: TextBox + colour
- Previous by thread: Re: why use the 'sealed' ?
- Next by thread: Re: why use the 'sealed' ?
- Index(es):
Relevant Pages
|
