I bumped into this when I tried to derive from System.Windows.Shapes.Path. This class is sealed - for no obvious reason (well at least I could not find any). The best reason I found so far (Book: "C# annotated standard" or http://msdn.microsoft.com/en-us/library/ms173150(VS.80).aspx) is that sealed classes enable the compiler to do specific optimizations. (How much performance does this optimization deliver?) I cannot image in what way this could be of any use to System.Windows.Shapes.Path. So far I never needed anything like a "sealed class" in C++ or in C#. I googled a bit but could not come up with any other good explanation or reason. (I don't even see why sealing System.Math, Brushes or Colors is such a good idea. I wanted to add a Sin function for another data type (an interval) - no way this could be done.) Most people either state that optimization is the reason or that they think that "sealed" does not make much sense. It basically forces one to abandon the idea of inheritance, that is central to these languages, and find some ugly way to code around this constraint.
Dear community, please enlighten me, why sealing System.Windows.Shapes.Path is such a good idea. My point of view right now is, that far too many classes are sealed.
too many classes are sealed and that doesnt mean we should'nt get along with our lives. My suggestion is for you to create a wrapper around the sealed class, or use the new Method extension to add new methods to your sealed class. Many reason's are behind why most of this classes are sealed. Remember that not only classes can be sealed because you can use the sealed keyword to seal a method from being overridden further.
Sometimes, most available keywords in a language are not to be used if the scope of your project does not require them. These keywords comes handy when you get deeper into a very large and non business project. An example is Dynamic casting, why on earth would you want to do dynamic casting if you are not using reflection, and generating some objects in the fly at run time.
As for me, the sealed keyword comes handy when you are building a system with multiple dynamic behaviours at runtime. The .NET JIT at runtime ignores inheritance calls like call virtual when it comes across sealed keyword, it just call the method directly, ignoring the fact that the method called might be in an inheritance chain.
It is also good to note that a class can be sealed for securability purpose. Especially when the said class relies on low level api, you might want to seal this class from futher corruption from inherited class(s).
It's an implementation issue. The Path class has virtual methods, overriding methods in Shape, that are internal. You can't derive from a class that has internal virtual methods. Making those methods public is not an option, that would allow a user to override them and break the base class. And require Microsoft to document methods that are irrelevant and should never be used or overridden. Sealed solves the problem. Hans Passant.
Thursday, July 24, 2008 2:04 PM
Microsoft is conducting an online survey to understand your opinion of the Msdn Web site. If you choose to participate, the online survey will be presented to you when you leave the Msdn Web site.