2

I've recently been using the System.Version class and have wondered why it, and some other similarly simple enough classes, are marked as Sealed (NotInheritable in VB).

Unlike some more complex classes I don't see what such a class would gain by being sealed.

As far as I can tell the source for Version does not imply any reason.

Is there a published/official (i.e. not opinion based) reason for this? Is there some problem that may be caused by deriving from it? Specifically for the case of Version, or failing that for similarly simple classes.

Background: I have had to recreate the Version class to make it easier to use it with two-way binding as the MS version has ReadOnly properties. But I'd need to know if deriving would cause some issue

Joey
  • 344,408
  • 85
  • 689
  • 683
Toby
  • 9,696
  • 16
  • 68
  • 132
  • 1
    Would that answer be enough http://stackoverflow.com/a/7777674/920557 ? see the [2] part – Eugene Komisarenko Apr 26 '17 at 12:13
  • @EugeneKomisarenko Thanks, somewhat. Part 1 is obvious as to why an *application* programmer may seal a class (as opposed to a CLR programmer). Part 2 gives information that sounds logical but is based on heresay and doesn't make much sense considering that MS base classes are there to save us doing work, not force us to duplicate it. I'd prefer a more concrete source/reason if possible. – Toby Apr 26 '17 at 12:20
  • I believe in designing for inheritance or prohibiting it. Designing for inheritance takes some work and will usually limit implementations further along. With this in mind, classes should be either sealed or designed to be able to inherit them. What if you have an implementation from a base class that you have no control over? A sealed class prevents base class problems you have no control over and isnt intended to be inherited. – Trevor Apr 26 '17 at 12:26
  • 2
    see: [Why Are So Many Of The Framework Classes Sealed?](https://blogs.msdn.microsoft.com/ericlippert/2004/01/22/why-are-so-many-of-the-framework-classes-sealed/) – TnTinMn Apr 26 '17 at 15:03
  • For future reference, the Ingo Rammer article mentioned in the comments of the page linked to by @TnTinMn is available in the internet archive here http://web.archive.org/web/20061110133859/http://www.thinktecture.com/Resources/Articles/SealedIsGood.html – Toby Apr 27 '17 at 09:58

1 Answers1

1

Version is a class representing a “value”, similar to DateTime, but being too large to comfortably fit into a struct, it's class. The same design principles apply, though. Types representing values should be immutable and sealed (value types are always sealed).

You can also clearly see other hallmarks of values:

  • object.Equals and object.GetHashCode have been overridden.
  • It implements IEquatable<Version>
Joey
  • 344,408
  • 85
  • 689
  • 683
  • Is there a rule, or rule of thumb on when a struct is "too large"? Coming from a C background I *generally* like to keep my structs solely for fields; if they need functionality then that's a class. – Toby Apr 26 '17 at 15:00
  • 2
    @Toby, for general guidelines, see: [Choosing Between Class and Struct](https://msdn.microsoft.com/en-us/library/ms229017(v=vs.110).aspx). – TnTinMn Apr 26 '17 at 15:22
  • For my future reference, in this specific situation my "BetterVersion" class should probably actually *wrap* the CLR `Version` class rather than inheriting from it ("is-a" relationship), composing from it ("has-a" relationship) or reproducing it. – Toby Apr 27 '17 at 10:07