Even if the fault were with sealing, that doesn't mean sealing a class is a negative thing or a drawback.
There are always good reasons to seal classes, including those situations where you are building something that's intended to be opaque and "black box"; as Meyers said for Effective C++ (which still carries over into this world), either design for inheritance, or prohibit it. Usually this begs a fair question: Why wouldn't you design for inheritance? Largely for design/implementation aesthetic and simplicity issues. When a subclass gets hold of a protected method and overrides it, the subclass can, without realizing it, create violations of invariants established in the base class. This is why in WinForms, for example, IMHO it's usually better for subclasses to hook the event handlers rather than override the protected On...() methods, as when you override you have to have awareness of the base class implementation in order to know if/when you need to call that base class method, and that implementation detail is always subject to change in a later release of the toolkit. This is what eventually brought MFC to its knees--too much loss of encapsulation of its internal processing. This actually happened in real life, by the way, on one of the first large-scale C++ toolkits created. Stroustrup documents, in "Design & Evolution of C++", that Mark Linton, the creator of the InterViews toolkit, begged and pleaded for a protection level in between public and private, such that inherited members could see fields but others couldn't. He relented and added protected. During the first C++ standardization meeting, years later, Linton was there arguing just as hard *against* protected, saying derived classes (and their creators) had screwed things up so much he swore it off forever. Either design for inheritance, or prevent it entirely. In the case of MsgBox, Microsoft chose the latter, and while you might disagree with it, you can't fault them for it--designing for inheritance is tricky. For whatever it's worth, the Java community went through this same heartache years ago when Sun decided to seal the String class in JDK 1.1; it wasn't sealed (the keyword is final in Java) in 1.0, and many people built subclasses of String that added interesting utility methods to the class, and Sun's sealing String broke that. It raised a huge hue and cry within the community, but over time, we learned the more general rule that inheritance isn't the primary form of reuse, and that those utility methods didn't really belong on String in the first place. (The main reason they chose to finalize String, however, had nothing to do with design purity, as I understand it--they were concerned that people would extend String in ways to violate some of the JVM assumptions regarding Strings, such as immutability.) Today, the Java community is far more interested in components, not inheritance, as the principal form of reuse. Given the similarities between Java and .NET, it would be a wise lesson to learn earlier rather than later, IMHO. Ted Neward Author, Presenter, Consultant Java, .NET, XML services http://blogs.tedneward.com > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Ian Griffiths > Sent: Tuesday, December 13, 2005 12:19 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Msgbox Question > > > Yes, especially seeing as MS have selfishly sealed anything > > remotely useful from sub-classing of the MessageBox class. > > Sealing has nothing to do with it. The limitation is intrinsic to what > it does, and sealing contributes nothing to that problem. > > In fact, it's not actually sealed in .NET v2.0. The superficial reason > you can't derive from it is the same reason you can't instantiate it: > its constructor is private. But that's not the underlying reason - even > if they changed this and let you instantiate and derive from the class, > the limitation would remain. > > Sealing is irrelevant here. > > First of all, MessageBox.Show is static. In fact all the members of > MessageBox are static. You never actually instantiate the MessageBox > class. > > Even if you could derive from it, there's nothing useful to inherit. > Logically speaking, MessageBox is a namespace containing a bunch of > global functions. Except of course C# doesn't support global functions, > so they have to be wrapped up as static methods in a class. If the CLS > required .NET languages to support global functions, MessageBox probably > wouldn't be a class - logically speaking its members all behave exactly > like global functions. > > So even if you could derive from MessageBox it wouldn't serve a useful > purpose. (No more than it would be meaningful to deriving from a > namespace.) > > The limitation is, as you say, that the class isn't very .NET. (And > that's because it's a straightforward wrapper around simple procedural > Win32 API.) The fact that you can't derive from MessageBox isn't the > cause of the problem. > > If they did let you derive from it, you'd simply be able to waste some > time discovering you can't extend it. (At which point, you could > reasonably say "They should have sealed this!") > > > (Sorry for the rant - it's just that there's a persistent meme that's > been doing the rounds for the last few years: this idea that sealing is > the cause of limitations rather than the expression of intrinsic > limitations... So when sealing is incorrectly identified as the cause of > a problem, I feel the need to point out that it's not! :) ) > > > -- > Ian Griffiths > > -----Original Message----- > From: Kelly, Brady > > > MessageBox() (the historical ancestor of the WinForms version) > > was historically a pretty black-box thing; if you need that level > > of control you probably want to write your own similar routine. > > > > Ted Neward > > Yes, especially seeing as MS have selfishly sealed anything remotely > useful from sub-classing of the MessageBox class. > > Probably because there is nothing to inherit from the very Not.NET > class. > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
