Re: why use the 'sealed' ?

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





"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.1ce887beddaa06fc98c0c5@xxxxxxxxxxxxxxxxxxxxxxx
> 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


.

Relevant Pages

  • Re: XP and string paths
    ... > the "Lcase" function is suddenly no longer available to Excel? ... > that occurs because of Windows XP. ... > string functions that Excel uses has become ... > is the usual "missing reference" problem. ...
    (microsoft.public.excel.programming)
  • Re: Windows versus Application Security
    ... Public Property UserNameAs String ... What is the equivalent in a Windows Application? ... So you would just have a login entry from that check the user likely from ... managing and removing windows domain accounts are not the ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: problem logging off and shutting down
    ... One using the Windows OS CD ... using repar from the setup menu and another microsoft repair tool that I ran ... I have been all over the Microsoft website and internet trying to ... #1 is a String Value ...
    (microsoft.public.windowsxp.general)
  • Re: Ada Interfaces and the Liskov Substitution Principle
    ... Polymorphism and references come hand in hand if you need the ability ... But it would be in vain, because assigning class-wide ... How would you pass an UTF-8 string to GTK+ ...
    (comp.lang.ada)
  • Re: VB, sending messages to another app using SendMessage / PostMessage.
    ... Windows will transport the text back and forth ... string is considered a null string. ... > Public Sub New ... As Int32 ...
    (microsoft.public.vb.winapi)