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.

Conclusion

Late binding isn’t difficult in C# as long as you can use conditional casting or dynamic to implement it.

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.

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, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

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