It’s a bit of a trap, of course, a class “sealed” we can not inherit … Yet the need exists. For example a differentiated String. How to get around the ban of the Framework? Is it possible?
Why
This is the first question, and perhaps the most important one. Why want to create descendant types of sealed classes? How can this be useful?
If I speak of utility it is good because the code must answer this imperative, all code without exception. We code to do something useful. Otherwise coding does not make sense.
Take the String class. The framework does not allow the creation of classes by inheriting and to block any desire in this sense, the class String is sealed. The designers of the Framework have definitely closed this door. But they opened another: class extensions. This allows to expand the possibilities of any class, even sealed, so of string too.
This would be perfect if the need to inherit a class was limited to want to add methods … But this is not the only motivation possible!
Take a case in point: you create software that allows you to enter many different class parameters using a PropertyGrid (like the Windows Forms that can be used without problems in WPF). Within such a mechanism you can usually define your own custom editors, which depend on the type of the value. For example, for a property of type Color you will be able to write a publisher offering a Pantone color chart and a “pipette”. This will be more enjoyable for your users than blindly typing a hexadecimal code to define a color.
Imagine for a second that among these parameters that will be entered in a PropertyGrid (or its equivalent WPF or UWP) there are some character strings defining for example the name of an external file.
In such a case you want that in addition to a simple string editor also displays a small ellipsis button “…” that will allow the user to browse the disks to directly select an existing file name. Maybe even the area will handle drag’n drop from the explorer.
Alas … Either you save the new editor for the name of a specific property (which is very constraining and source of bugs), or you save it for its type, String, and then it will be all the strings that will benefit from the file browser, which makes no sense!
What would not it be easier to just define “public class Filename: string {}” and Hop! the case would be played!
The editor would be registered for the type “Filename”, the file names in the parameters would not be of type “string” but of type “Filename” and everything would be for the best in the best of worlds.
So here is a concrete case that shows the obvious utility of creating classes inheriting from string (or other sealed classes), even totally empty, just to create a CLASSification, at the very core of object programming anyway …
I do not doubt that enlighten by this example you find others, even totally different.
In any case we have answered the first question. This is useful, and then object programming is based on inheritance to solve many problems, so there is a natural legitimacy to want to inherit a class. “Sealed” is a little frustrating. It’s almost a misstep in an object world. The justification for the more efficient code produced by a sealed class seems to me to be rather artificial and difficult to defend. But C# is well done, perfection does not exist. Fortunately the great flexibility of the language makes it possible to work around this kind of problem quite easily!
How
I already told you: it is not possible, do not insist! …
But as this ticket would not exist if I did not have a solution to offer you, you say that there must be a “trick”.
The string class is sealed. So there is no magic “thing”. No way to tinker with the Framework either. I told you that it is not possible!
But there is a solution, a little less direct but quite reasonable and “clean”.
It simply means developing another class that does not inherit anything.
Hou there! Reinventing the string type just for a classification reason seems downright overkilling!
That’s right, and we will not be embarking on such a complex path. On the other hand we can be cunning and try to write as little as possible while passing through a string …
In fact it’s quite easy but it uses little used syntactic elements like the implicit operators.
The trick is to create a “normal” class inheriting nothing, and having a single property, Value, of type string (or another type sealed which one would like to inherit).
Of course it’s not hard to write but it does not solve the problem. It is not possible to pass our class for string. Everywhere it will change ‘x =’ foo ” by ‘x.Value = “foo”‘ and that’s not what we’re looking for!
This is to forget the “implicit” operators that make it possible to convert an instance of a class into other types (and vice versa). Implicitly. That is without having to write anything in the code that uses the said class to convert.
To begin we will have a code that looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
public class MyString : IEquatable<MyString>, IConvertible { private string value; public MyString() { } public MyString(string value) { this.value = value; } public string Value { get { return value; } set { this.value = value; } } public override string ToString() { return value; } public static implicit operator MyString(string str) { return new MyString(str); } public static implicit operator string(MyString myString) { return myString.value; } ... |
The MyString type declares a Value property of type string, but above all, it declares two implicit operators: one that converts one string into MyString, and the other deals with the opposite direction.
It’s almost everything. It works. I can write ‘MyString x =’ foo ” and vice versa (assign a variable of type string directly a MyString type variable).
In reality, it will be necessary to deal with other details, such as equality operators for example, or conversions of type (IConvertible interface), etc.
But most of this code can be directly vampirized from the string class because the Value value is of this type and our class contains nothing else to convert.
We arrive at a final code of this type (assuming as in the above statement that we want to have a custom string to enter the name of a dictionary, so a DictionaryNameString):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 |
public class DictionaryNameString : IEquatable<DictionaryNameString>, IConvertible { private string value; public DictionaryNameString() { } public DictionaryNameString(string value) { this.value = value; } public string Value { get { return value; } set { this.value = value; } } public override string ToString() { return value; } public static implicit operator DictionaryNameString(string str) { return new DictionaryNameString(str); } public static implicit operator string(DictionaryNameString dictionary) { return dictionary.value; } public bool Equals(DictionaryNameString other) { if (ReferenceEquals(null, other)) return false; return ReferenceEquals(this, other) || Equals(other.value, value); } public override bool Equals(object obj) { if (ReferenceEquals(null, obj)) return false; if (ReferenceEquals(this, obj)) return true; return obj.GetType() == typeof(DictionaryNameString) && Equals((DictionaryNameString)obj); } public override int GetHashCode() { return (value != null ? value.GetHashCode() : 0); } public static bool operator ==(DictionaryNameString left, DictionaryNameString right) { return Equals(left, right); } public static bool operator !=(DictionaryNameString left, DictionaryNameString right) { return !Equals(left, right); } #region IConvertible Members public TypeCode GetTypeCode() { return TypeCode.String; } public bool ToBoolean(IFormatProvider provider) { return Convert.ToBoolean(value, provider); } public byte ToByte(IFormatProvider provider) { return Convert.ToByte(value, provider); } public char ToChar(IFormatProvider provider) { return Convert.ToChar(value, provider); } public DateTime ToDateTime(IFormatProvider provider) { return Convert.ToDateTime(value, provider); } public decimal ToDecimal(IFormatProvider provider) { return Convert.ToDecimal(value, provider); } public double ToDouble(IFormatProvider provider) { return Convert.ToDouble(value, provider); } public short ToInt16(IFormatProvider provider) { return Convert.ToInt16(value, provider); } public int ToInt32(IFormatProvider provider) { return Convert.ToInt32(value, provider); } public long ToInt64(IFormatProvider provider) { return Convert.ToInt64(value, provider); } public sbyte ToSByte(IFormatProvider provider) { return Convert.ToSByte(value, provider); } public float ToSingle(IFormatProvider provider) { return Convert.ToSingle(value, provider); } public string ToString(IFormatProvider provider) { return value; } public object ToType(Type conversionType, IFormatProvider provider) { return Convert.ChangeType(value, conversionType, provider); } public ushort ToUInt16(IFormatProvider provider) { return Convert.ToUInt16(value, provider); } public uint ToUInt32(IFormatProvider provider) { return Convert.ToUInt32(value, provider); } public ulong ToUInt64(IFormatProvider provider) { return Convert.ToUInt64(value, provider); } #endregion } |
And here is a custom “string” class, usable as a string and offering the same services overall in 99% of cases (assignments in one direction or the other, conversions).
Little more: our class is not “sealed” … Just call it “MyStringBase” and then inherit this class to create heaps of custom “string” types.
Apart from the example I gave, we can imagine many cases where doing an “if (variable is MySpecialString) …” can simplify things a lot. While maintaining a simple and clear writing, a clean and maintainable code.
Conclusion
C# is a very subtle language, it knows how to create blockages that avoid large pellets (like the fact that it does not allow multiple inheritance or the existence of sealed classes) but in return it offers many exit doors allowing elegantly to do what you want. It remains to be mastered to get there, and that’s a challenge, the more we work with this language, the more we understand that we are far from knowing everything!
