I’m really impressed by the dynamic keyword as a part of the .NET 4.0 framework. Dynamic really opens up a lot of capabilities. Dynamic will allow me, as I develop software, to avoid wrapper components and avoid having to use reflection in certain places. The first scenario is where I had two similar, but distinct objects, in which I needed one common interface. This is useful when the two objects have a similar API, but the API’s are disparate because of no common interface or base class. I would use a class like the following:
public class MyWrapper : ICommonInterface
{
private MyObject1 _o1;
private MyObject2 _o2;
public MyWrapper(MyObject1 o) { _o1 = o; }
public MyWrapper(MyObject2 o) { _o2 = o; }
//Method defined in interface, which both first and second object have.
public void DoThis()
{
if (_o1 != null)
_o1.DoThis();
else
_o2.DoThis();
}
}
It was painful to do this at times, but both objects were closed for modification, and therefore I needed a wrapper with one common signature. However, with dynamic, this can all go away and we can implement this more simply:
public class MyWrapper : ICommonInterface
{
private dynamic _o;
public MyWrapper(dynamic o) { _o = o; }
//Method defined in interface, which both first and second object have.
public void DoThis()
{
_o.DoThis();
}
}
We may not actually need the wrapper, but if we do (in the case where we need the object to implement ICommonInterface and the objected passed in is an object closed for modification and is missing this interface), we can use the dynamic and assume it exposes the same interface. Otherwise, if it doesn’t, you’ll find out at runtime 
Another reason to use dynamic is to avoid reflective calls, which can clean up some of the code and may add some performance benefits. For instance, I could replace this code:
private object GetValue(object original)
{
MethodInfo method = original.GetType().GetMethod("GetValue");
return method.Invoke(original, new object[] { });
}
With this:
private object GetValue(object original)
{
dynamic o = original;
return o.GetValue();
}
That is, or course, a simplistic example; however, there are times where this actually does come in handy, assuming that that value passed in does actually have the GetValue method. The benefit to the reflection approach is that I could actually check for the existence of the method by adding an “if (method != null)” above before trying to execute it. I do not have that luxury with the dynamic keyword.
While dynamic provides benefits to your application architecture, there are times when good object oriented design can circumvent both the need for reflection and dynamic, as in the following:
private object GetValue(object original)
{
if (original is IValueGetter)
return ((IValueGetter)original).GetValue();
else
return null;
}
Here we assume that anytime we need to get a value, the object has an IValueGetter interface; if not, we return null because we don’t care about getting the value. Again, a simplistic view, but you get the point.
