CODEWITHSUNDEEP
vb.netlate-binding
Tom K
Tom K

Reputation: 319

Late Binding in VB

From what I have read so far, late binding is defining a variable as Object and then assigning it to the actual object later which is actually done at run time. I don't understand the point to that. Maybe this is the Java in me, but doesn't that limit the functionality to what is just in Object? It is like saying, "I want the potential of the extra stuff, but I don't want to have access to it." Is there an actual purpose for late binding in VB, or Java for that matter, that I'm overlooking?

Upvotes: 0

Views: 1312

Answers (2)

T.S.
T.S.

Reputation: 19394

What I seen - some early .NET adapters-developers were doing is - they were using late binding instead on interfaces. They would declare two or more types

Public Class Handler1
   Public Sub Execute()
       ' do something
   End Sub
End Class

Public Class Handler2
   Public Sub Execute()
       ' do something else
   End Sub
End Class

And they would stick this thing into session object

If someting = 1 Then 
    Session("Handler") = New Handler1()
Else
    Session("Handler") = New Handler2()
End If

And then, to process something they would do 

Session("Handler").Execute()

There we go. This is not pretty or smart. But that was instead of proper programming like this (Imagine handlers implement IHandler interface with method Execute)

Dim h As IHandler = TryCast(Session("Handler"), IHandler)
If h IsNot Nothing Then
    h.Execute()
End If

Here is where downfall of late binding starts: In the case of late binding, someone, somewhere, can rename a method Execute and compile code nicely. Release. And only then, at runtime, get a problem.

Late binding was good when we used to deal with interop and COM. Other than this, it is detrimental.

Upvotes: 1

jmcilhinney
jmcilhinney

Reputation: 54477

You have it backwards. By using early binding you are limiting yourself to just the members of the type of the variable. With Option Strict On, a variable declared as type Object will only allow you access to members of type Object, regardless of the type of the actually object it refers to. With Option Strict Off, you can access a member of any name on a variable of type Object and the compiler won't complain. It's only at run time that any type checking is done so, as long as the actual object assigned to the variable has a member with that name, the code will run.

Probably the most common use for late binding is Office Automation. There are other options now but, in the past, if you referenced an Office library and used the specific types it contained, facilitating early binding, then you were limited to that specific version of Office. In order to support multiple versions, you had to forgo the reference, declare all your variables as type Object and use late binding. As long as the version of Office present at run time included the specified members on the objects used, the code would run without issue.

By the way, late binding doesn't require using type Object, although it is probably the most common. It just means that the reference is a less derived type than the object and you use a member of the object's type that the reference's type doesn't have, e.g. you use type Control and then use a member specific to type Button.

Upvotes: 2

Related Questions