Dynamic Overload Resolution

Both when coding in C++ and C# I’ve had problems with overload resolution being static. There are workarounds, for example the visitor pattern but it requires quite an effort to implement. More importantly it cannot be implemented without changing the visited element. With C#4’s dynamic keyword there is finally a better solution.

To illustrate the problem I’ll implement the ITransportationService interface.

public interface ITransportationService
    void TransportAnimal(Animal a);

I’ll implement it by delegating the transportation work to the AnimalTransport class. The problem is that AnimalTransport has a special overload for elephants and the ITransportationService.TransportAnimal interface doesn’t.

A Simple Transport

First I’ll show a simple transport, which makes use of the AnimalTransport class.

public static class AnimalTransport
    public static void LoadAnimal(Animal animal)
        Debug.WriteLine("Putting " + animal.Name + " in a cage.");
    public static void LoadAnimal(Elephant elephant)
        Debug.WriteLine("Loading " + elephant.Name + " on a trailer.");
public class SimpleTransportation : ITransportationService
    public void TransportAnimal(Animal a)

Executing the code with an elephant shows a problem.

Transporting an elephant with SimpleTransportation...
Putting Hanibal in a cage.

I think that it might be a problem trying to put Hanibal the elephant into an ordinary size pet cage.

A Flexible Transport with Dynamic

Introducing the dynamic keyword handles the situation.

public class FlexibleTransportation : ITransportationService
    public void TransportAnimal(Animal a)

Executing the code now loads Hanibal on a trailer instead.

Transporting an elephant with FlexibleTransportation...
Loading Hanibal on a trailer.

Objectoriented Principles

Objectorientation is all about separation of concerns and encapsulation of behaviour. In most cases, it is appropriate to defer to the class itself to decide behaviour that depends on the runtime type. For example, a RunDistance method on the Animal class would be an ordinary virtual (and probably abstract) method, letting each concrete implementation return how fast the specific animal runs.

In this case however I don’t think that it is appropriate. The animal itself should be completely ignorant about how it is transported.
Looking at the AnimalTransport class I think that it is completely reasonable to have a special overload for the elephant. It is huge and requires special handling compared to ordinary animals like cats and dogs.

It is also totally appropriate that the ITransportation interface knows very little about the details of the Animal class hierarchy. Adding a separate overload (if we are at all allowed to change it) there for the elephant would reveal details at the wrong place.
As I mentioned in the beginning of the post the visitor pattern can solve the problem. Unfortunately that requires that the Animal class hierarchy has support for visitors, which is probably not the case if it comes from a library.

I think that using dynamic in this case makes the code clean, elegant and still type safe. If all other classes are already existing and not possible to change, the only other alternative would be manually check the type during runtime.

  • Leave a Reply

    Your name as it will be displayed on the posted comment.
    Your e-mail address will not be published. It is only used if I want to get in touch during comment moderation.
    Your name will be a link to this address.
Software Development is a Job – Coding is a Passion

I'm Anders Abel, an independent systems architect and developer in Stockholm, Sweden.

profile for Anders Abel at Stack Overflow, Q&A for professional and enthusiast programmers

Code for most posts is available on my GitHub account.

Popular Posts



Powered by WordPress with the Passion for Coding theme.