Page 1 of 4
The concepts of late and early binding can be confusing, mainly because they aren’t really as different as they might first seem.
There is also a general belief that late binding in C# is sophisticated but hard work and in VB .NET less sophisticated but much easier.
There is a sense in which late binding is really isn’t any different from early binding – you could say it’s more a state of mind of the programmer, but it’s high time to look in more detail at how it all works.
What is late about late binding?
When you work with a strongly typed language then early binding is the norm – indeed it might even be the only type of binding allowed.
The basic idea is that you declare the type of every variable you use within the code and this allows the compiler to check what you are writing for correctness. It can also allow the IDE to provide help by listing the methods and properties that you can use as in the Intellisense feature of Visual Studio.
Where early binding starts to show its limitations is when you need to write some code that deals with a range of data types. If at this point you are thinking “generics” then yes but it’s still, in concept, early bound. If you express an algorithm as generic code all that happens is that early binding is deferred until you specify, at design time, the types to be used with the template.
Late binding implies that the type of an object isn’t known until run time and this goes beyond generic templates. It is useful to change from thinking about variables or instantiated classes to “pointers” or more properly references to instances.
The idea is that you have a pointer or reference to an instance of an unknown type – unknown that is at design time. To make use of the unknown type you have to discover its type at run time using some sort of dynamic type information.
In .NET this dynamic type information is supplied by the “reflection” classes. In fact the reflection classes provide facilities that go beyond simple late binding to allow you to create types and instances dynamically.
So the key idea in late binding is the use of a reference to an object whose type is only determined dynamically at run time.
In reality all objects are managed using references, even if they are early bound, so the only real difference is the programmer’s ignorance of the type at design time. This is a key observation – if the programmer knows the type then it’s early binding; if the programmer doesn’t know the type it’s late binding.
Let’s see what happens if we pursue this idea.
Late binding in action
So much for theory; it’s time for an example, and examples are always better the simpler they are. In the real world late binding usually occurs in some messy, complicated, way that obscures what is happening. Let’s start with C#.
In this case we need a class with a single method to try things out:
public int Method1(string text)
Now we are going to create and use an instance of the class but we are going to pretend not to know its type.
As we don’t know its type we need an object variable to refer to the instance:
late = new Class1();
Clearly in this example the programmer does know the type of the instance stored in late at design time! This is even more obvious when you write the instantiation as:
object late=new Class1();
The compiler also knows the type of “late” at design time but C# it does its best to forget this. If you now write:
int count= late.Method1("Hello World");
you will get a compile time error message which says that “object does not contain a definition for Method1” which is indeed true. It is in this sense that it is said that C# doesn’t support automatic late binding.
But don’t give up on it just yet - dynamic types introduced in C# 4 make it easy.
VB and late binding
Turning now to VB .NET, things are much simpler as long as we set:
Option Strict Off
For arguably good reasons VB feels a bit embarrassed about handling late binding so casually and insists that you explicitly turn it on.
If you do this then as long as you know the type of a class at design time the compiler will let you make use of it. For example, with the same definition of Class1 in VB we have:
Dim late As Object = New Class1
Dim i As Integer = late.Method1( _
ith Option Strict Off this works; with it On it fails in exactly the same way that the C# does and generates a compile time error.
Of course if you make a mistake and late reference an instance that doesn’t have a Method1 then you get a runtime error. This is the terrible disaster that both C# and Strict On are trying to save you from.
Notice that the VB .NET approach is a bit like saying:
“I think that object is some type that has a method called Method1. If so call it. If not – oops!”
Hardly a strongly typed approach.