Defeating strong typing in .NET

Home » Defeating strong typing in .NET

Defeating strong typing in .NET
- By Willem Meints
- 15 years ago
- 0 comments
- .NET
I’ts been quite a while since my last post. I have been busy with two projects that both need a lot of attention. Some time ago I discovered a really weird way of passing stuff into a method that totally defeats the idea of having descriptive classes and properties. It actually is some kind of excellence, because you don’t see these kind of constructions very often.

The "anonymous" class

.NET has native support for anonymous classes now-a-days. However you can appearantly create "anonymous" classes in .NET 1.0, as the following sample demonstrates:
```
   1: object[] parameters = new object[] {
```
```
   2:     &quot;Hello world&quot;,
```
```
   3:     new object[] { 1,2,3, },
```
```
   4:     &quot;Description&quot;,
```
```
   5:     0,
```
```
   6:     23
```
```
   7: };
```
If this code had a smell… On the other hand, I can imagine why someone would do this. It’s very flexible and you don’t have to create a class for just passing some related information to a method. Also, if I wasn’t there to break the code, it would never have been discovered.

The anonymous class

When driving home this afternoon I came up with a method to make the above even more interesting. What if I could actually make a dynamic object in C#, without the use of the new .NET 4.0 feature of dynamic types? It’s not that you want this, but it sure made me smile. The object is essentially the same as the previous sample. It’s better in a sence, since it has properties and is as such not completely nameless. However for the properties to be accessible you will need to rely on reflection:
```
   1: public static class AnonymousTypeExtensions
```
```
   2: {
```
```
   3:     /// <summary>
```
```
   4:     /// Gets the value of an anonymous property
```
```
   5:     /// </summary>
```
```
   6:     /// <param name=&quot;input&quot;></param>
```
```
   7:     /// <param name=&quot;propertyName&quot;></param>
```
```
   8:     /// <returns></returns>
```
```
   9:     public static object GetPropertyValue(this object input, string propertyName)
```
```
  10:     {
```
```
  11:         Type objectType = input.GetType();
```
```
  12:         PropertyInfo property = objectType.GetProperty(propertyName);
```
```
  13:&#160; 
```
```
  14:         return property.GetValue(input, null);
```
```
  15:     }
```
```
  16: }
```
Combine this with the following sample and you have an anonymous type that can be transferred outside of the method and does not give any compile warnings:
```
   1: namespace AnonymousTypesSample
```
```
   2: {
```
```
   3:     class Program
```
```
   4:     {
```
```
   5:         static void Main(string[] args)
```
```
   6:         {
```
```
   7:             object something = new 
```
```
   8:             {
```
```
   9:                 Greeting = &quot;Hello world&quot;,
```
```
  10:                 SubItems = new {
```
```
  11:                     Item1 = 1,
```
```
  12:                     Item2 = 2,
```
```
  13:                     Item3 = 3
```
```
  14:                 },
```
```
  15:                 Description = &quot;Description&quot;,
```
```
  16:                 Index = 0,
```
```
  17:                 Id = 23
```
```
  18:             };
```
```
  19:&#160; 
```
```
  20:             Console.WriteLine(something.GetPropertyValue(&quot;Greeting&quot;));
```
```
  21:         }
```
```
  22:     }
```
```
  23: }
```
Conclusion

So why does this article carry the title "defeating strong-typing in .NET? Well, there are actually two sides to the strong typing story in the .NET framework. Although the objects in example 1 do have a type that isn’t just object, it doesn’t tell developers what to do with this amorphous blob of data. So the first thing is runtime safety. In C++ you can cast everything to everything as long as the underlying memory is either not touched or has a similar layout as the object from which you casted. In .NET however you cannot do this, as it is a source of buffer problems and possible security leaks. This cannot be defeated, because the runtime and the compiler force you to follow this.

The second part of strong-typed-ness is actually the strong-named-ness of things. An amorphous blob of objects will cause a lot of trouble when some developer comes a long and starts breaking the code that uses the blob. He doesn’t know what it is and will try to cast the wrong object in the array, etc. Although the second sample is a little bit better, it still doesn’t tell the developer what it is. I still have to know what is there. Also the compiler will not warn you that a property doesn’t exist, since it only has a blob and a string to look at. And that is of course perfectly fine for the compiler.

In the end I think it’s just funny to see what you still can do to make a mess out of todays strong typed, garbage collected and extensive frameworks.

Share this

Click here to cancel reply.

Leave a Reply