Early vs. late binding

In the good old COM days the early vs. late binding issue was an issue that all developers should deal with. This article describes the pros and cons of the early vs. late binding issue.

This days I havnt been dealing with this issue very much all though the System.Reflection namespace has been used a lot it is not excatly the same. The reflection namespace allows us to examine assemblies for methods and properties but is done to make a system very generic and should be designed not to fail if a specific method or property is not found.

The tendency in more and more generic CMS systems and internal modules raise this issue again.
Lets have a look at some code sample

 public class MyItems  
 {  
   public Dictionary items = new Dictionary();  
   public Dictionary Items  
   {  
     get  
     {  
       return items;  
     }  
   }  
 }  
 public class MyClass  
 {  
   public void OnLoad()  
   {  
     MyItems items = new MyItems();  
     String s = Items["Item1"];  
   }  
 }  

Two classes have been made. One that contains an Items property that returns a generic dictionary with all available items and one that uses late binding when accessing the Items property. It is late binding because we dont know if the item exists and the compiler cant warn us if we make a spelling error.
Depending on how the Items property are created the application might fail if a none existing item is accessed. Other applikations might just return an empty string but this might as well result in undesired result.

A far better way, though not solving but makeing handling of these issues more simple, is to create extension methods like this.

This results in a new static class and a change in the MyClass

 public static class MyExtensionMethods  
 {  
   public static String Item1(this MyItems item)  
   {  
     if (!item.Items.ContainsKey("Item1"))  
       throw new ApplicationException("Item1 does not exists");  
     return item.Items["Item1"];  
   }  
 }  
 public class MyClass  
 {  
   public void OnLoad()  
   {  
     MyItems items = new MyItems();  
     String s = items.Item1();  
   }  
 }  

This still uses late binding but it is now done in a more controlled manner and all classes that uses MyItems and has a using MyExtensionMethods; now can use the Item1() extension.
If the Item1 for some reason should change name or some other handling should be done if the item does not exists or is empty it only needs to be done place. And if you need to change the Item1() extension name the compiler now helps you find all references.

All though this sample code does not remove the late binding it sure removes much of the complexity of it by putting it together in one place.
Of course you can wrap the MyItems class in a wrapper class that exposes Item1 as a property which will give the same result as the extension method but requires more code.
And why not use this very neat feature in the .NET 3.5 framework called ExtensionMethods?