Late Binding - Myths and Reality
Written by Mike James   
Tuesday, 30 September 2014
Article Index
Late Binding - Myths and Reality
Casting
Real late binding

 

Real late binding

You can tell that I’m of the opinion that the whole notion of late binding, and in particular the use of explicit reflection to deal with it, is a bit of a misguided enterprise.

If you believe that there are occasions when the programmer is ignorant of the potential run time types at design time then you really do have to use reflection and implement something really dynamic.

However, I can’t really see how you can actually do anything useful in a state of complete ignorance of the run time type!

How can you possibly know what to call and how to call it if you really are that ignorant?

At worst you have to be working with a small, defined, number of alternative incompatible classes or an unlimited and expandable number of derived classes. In either case you can use conditional casting to solve your problem. You can also make the handling error free and robust simply by testing the type before working with it and making your assumptions about run time type explicit.

This is a strongly typed approach to the problem of late binding.

Notice also that it is very similar to the approach that you have to take in a dynamic language like JavaScript. The only real difference is that you have to test, at run time, for the existance of the method or property you want to use rather than a class. 

The only exceptions to the above reasoning that I’ve found is where what you want to do to the unknown object is so general that you can indeed do it without an exact knowledge of how it works or when the situation is so specific that every possible class no matter what its type has a given method.

For an example of the first case suppose US is an object reference to an unknown struct. In this case we can write a late bound method that processes the struct, even though we know nothing at all about it, as long as we stick to something simple like displaying the all of the field names. In this case reflection is exactly what we need:

Type T=US.GetType();
FieldInfo[] members=T.GetFields();
foreach(FieldInfo member in members){
 MessageBox.Show(member.Name);
}

The GetFields method returns an array of FieldInfo types which contain information on each field. You can generalise this example to cases where the fields require simple processing that doesn’t depend too much on their type – such as reversing byte order or coding of some sort.

For an example of the second method suppose every object we are going to process has a Method1 but we didn't know the objects type or even the range of types it might come from or derive from then before C# 4 and dynamic we would have had to use reflection. But now we can simply write:

dynamic anyobject;
 ...
anyobject.Method1();

Of course if every object has to have a Method1 to be use then a much more sensible arrangement would be to use an Interface definition and cast to the interface type before using the method.

csharp

Conclusion

Late binding isn’t difficult in C# as long as you can use conditional casting or dynamic to implement it and if you can it’s just as easy as using automatic late binding in VB .NET.

The advantages of explicitly declaring the expected run time types of late bound objects also seems to be a more robust approach to the problem and it is worth making use of it in VB .NET to augment the automatic late binding.

Related Articles

Type Systems Demystified

Dynamic C#        

Covariance And Contravariance - A Simple Guide       

Data Typing Is A Relic       

Strong Typing       

Weakly Typed Languages       

 

To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, FacebookGoogle+ or Linkedin,  or sign up for our weekly newsletter.

 

Banner


Deep C# - Casting the Escape from Strong Typing

Casting is one of the most confusing aspects of any modern language and it often makes beginners think hard. But if you know why you are doing it, then the how makes a lot more sense. We have encounte [ ... ]



Deep C# - Interface

Interfaces - what are they for? Not quite inheritance yet they seem to fit the same purpose. Find out in this extract from my new book, Deep C#: Dive Into Modern C#.


Other Articles

 

raspberry pi books

 

Comments




or email your comment to: comments@i-programmer.info



Last Updated ( Tuesday, 30 September 2014 )