I ran across a scenario the other day for creating a function to perform similar work on similar classes without having to be tightly coupled to any concrete type. I found a few viable options and will be doing some examples of each to work through the exercise completely. The first I want to talk through is the use of the dynamic keyword.
In short, using dynamic tells the compiler to ignore types at compile time and instead determine
dispatch based on the actual type at run time. Static binding of types does the exact opposite and performs a dispatch based on the concrete type. Since code always illustrates these academic discussions more clearly, I created a simple project. I have two examples of dynamic typing built into this single example. I created some classes to illustrate a few types that are completely unrelated to each other. I also created a single class that was an example of type inheritance.
public class Account
{
public String Name { get; set; }
public Double Balance { get; set; }
public Int16 AccountType { get; set; }
public Account()
{
Name = "Account";
Balance = 100.00;
}
}
public class Customer
{
public String Name { get; set; }
public Double Balance { get; set; }
public String CustomerType { get; set; }
public Customer()
{
Name = "Customer";
Balance = 900.00;
}
}
public class Employee
{
public String Name { get; set; }
public Double Balance { get; set; }
public String Department { get; set; }
public Employee()
{
Name = "Employee";
Balance = 500.00;
}
}
public class Payable : Account
{
public Payable()
{
Name = "Payable";
Balance = -100;
}
}
As you can see, the classes are completely independent of each other, but they have similar members. Using the dynamic keyword, we can create a function that deals with these types at runtime and interacts with expected members at that time.
static void WriteDynamicObject( dynamic thing)
{
Console.WriteLine("Name: "+ thing.Name + ", Balance: " + thing.Balance.ToString());
}
As long as the types I pass to this function have publicly accessible members named Name and Balance, this code will work with a complete disregard for compilation of any known type. Next, to illustrate using the dynamic keyword for instructing the runtime to resolve the type regardless of declaration, I created overloaded functions that take a concrete type at each level of inheritance.
static void WriteConcrete(Account thing)
{
Console.WriteLine("I am an Account Thing");
}
static void WriteConcrete(Payable thing)
{
Console.WriteLine("I am a Payable Thing");
}
Finally, a simple console application that illustrates how these items work and are either statically or dynamically resolved. The difference between the 'Concrete' functions is shown by the dynamic keyword telling the runtime to resolve this class at run time regardless of it's declaration. Also, notice the last item is not even a class at all, but rather a dynamic type declared simply to be passed to this helper function.
static void Main(string[] args)
{
// call writedynamicobject function for all concrete classes
Account a = new Account();
WriteDynamicObject(a);
Employee e = new Employee();
WriteDynamicObject(e);
Customer c = new Customer();
WriteDynamicObject(c);
//call function for a concrete class, but resolve type at runtime
Account p = new Payable();
WriteConcrete(p);
WriteConcrete((dynamic)p);
// dynamically create values and pass as a dynamic type.
WriteDynamicObject(new {Name="TotallyDynamicNonClass", Balance=250});
}
The output of this project illustrates how the runtime deals with each of these scenarios.
If you are like me, the first thought you have on using the dynamic typing pattern is along the lines of,
"Couldn't you just use an interface or inheritance to accomplish the same thing?" The answer is yes, assuming you are able to know those types at compile time. But, there are also times where you can't know the definitions at compile time. You can't compile the internet, but you can interface with it. I would be remiss if I didn't get into the downsides of this practice as well. This can open you up to having a program that is hard to maintain, difficult to debug and unit test and many similar issues. But, guns don't kill people, people with guns do. Dynamic typing doesn't make code difficult to manage, a programmer does those things with his or her architecture. This is not a magic bullet and should be used with great caution. The reason for using it is that some problems are inherently dynamic (e.g. web requests). While you may use reflection for this sort of problem today, you may find dynamic typing a more expressive approach to the same problem. Simply being dynamic in itself is a compelling argument.
Reflection introduces a tightly coupled dependency on a static mechanism. Dynamic methodologies are intent-based and trust the receiver to act upon the passed intent which creates a scalability unachievable by other means. The source files are available for download
here.
