El duck typing es una característica bastante frecuente en lenguajes dinámicos y que a veces se echa de menos cuando se trabaja con (casi todos los) lenguajes estáticos. Consiste en poder implementar de forma implícita un interfaz, es decir, si un objeto cumple con el contrato definido en el interfaz, aunque no lo haya declarado explícitamente, se considerará a todos los efectos que implementa ese interfaz.

La idea (y de ahí viene el nombre) es que si camina como un pato y nada como un pato, es que es un pato o al menos me sirve como tal, es decir, no me importa lo que sea siempre y cuando haga lo que necesito.

Veamos un ejemplo para entenderlo mejor:

public interface ICalculator
{
    int Add(int a, int b);
}

public class ValidCalculator : ICalculator
{
    public int Add(int a, int b) { return a + b; }
}

public class NotACalculator 
{
    public int Add(int a, int b) { return a + b; }
}

En este caso tenemos dos clases iguales ValidCalculator y NotACalculator que tienen los mismos métodos, pero una de ellas implementa el interfaces ICalculator y la otra no. En C# sólo podríamos usar como ICalculator instancias de ValidCalculator. Si C# soportase duck typing, aunque NotACalculator no haya declarado que implementa el interface ICalculator sí que se podría usar como tal.

Si el código anterior fuese nuestro, la solución sería muy sencilla: hacer que NotACalculator implementase el interface ICalculator y dejar de complicarnos la vida. El problema es que a veces necesitamos que una clase que no controlamos nosotros implemente un interfaz determinado.

La solución «de libro» a esto es aplicar el patrón adapter, que nos permite adaptar el interfaz de una clase para adecuarlo a nuestros requisitos:

public class CalculatorAdapter : ICalculator
{ 
    private readonly NotACalculator inner;
    public CalculatorAdapter(NotACalculator inner)
    {
        this.inner = inner;
    }

    public int Add(int a, int b)
    {
        return inner.Add(a, b);
    }
}

Lo bueno del patrón adapter es que además nos permite ajustar pequeñas diferencias en el interfaz, como pueden ser nombres de métodos, tipos de argumentos, etc.

Lo malo es que cuando la clase ya implementaba exactamente el interfaz, estamos escribiendo un código repetitivo y que no aporta mucho a la aplicación

Duck Typing con Castle.DynamicProxy

Para evitar escribir estos adapters podemos utilizar LCG y para eso una buena opción es aprovechar Castle DynamicProxy, del que ya hemos hablado por aquí para aplicar AOP con interceptores.

Mi objetivo es conseguir pasar este test:

[TestFixture]
public class DuckInterceptorTest
{
  public interface ICalculator
  {
    int AddNumbers(int a, int b);
  }

  public class NotACalculator
  {
    public int AddNumbers(int a, int b) { return a + b; }
  }

  [Test]
  public void DuckTyping_of_methods()
  {
    ICalculator calculator = DuckType.As<ICalculator>(new NotACalculator());
    Assert.That(calculator.AddNumbers(2, 3), Is.EqualTo(6));
  }
}

Quiero implementar un método DuckType.As<T>(target) para generar dinámicamente un adapter que implemente el interfaz especificado y redirija las llamadas a los métodos adecuados del objeto indicado. Vamos, lo mismo que antes habíamos hecho manualmente en el ejemplo, pero de forma genérica y reutilizable.

Pues resulta que hacer eso con DynamicProxy no es demasiado complicado (aunque depende un poco de cómo de detallistas queramos ser):

public static class DuckType
{
  public static T As<T>(object target) where T : class
  {
    var interceptor = new DuckTypingInterceptor(target);
    return new ProxyGenerator().CreateInterfaceProxyWithoutTarget<T>(interceptor);
  }

  private class DuckTypingInterceptor : IInterceptor
  {
    private readonly object target;

    public DuckTypingInterceptor(object target)
    {
      this.target = target;
    }

    public void Intercept(IInvocation invocation)
    {
      var methods = target.GetType()
                          .GetMethods(BindingFlags.Instance | BindingFlags.Public);

      // This should (probably) be cached
      var method = methods.FirstOrDefault(x => IsCompatible(x, invocation.Method));

      if (invocation.GenericArguments != null && 
          invocation.GenericArguments.Length > 0)
      {
        if (!method.IsGenericMethod)
          throw MissingMethodException(invocation);

        method = method.MakeGenericMethod(invocation.GenericArguments);
      }

      if (method == null)
        throw MissingMethodException(invocation);

      invocation.ReturnValue = method.Invoke(target, invocation.Arguments);
    }

    private MissingMethodException MissingMethodException(IInvocation invocation)
    {
      return new MissingMethodException(
                   string.Format("Cannot found compatible method {0} on type {1}", 
                     invocation.Method.Name, target.GetType().Name));
    }

    private bool IsCompatible(MethodInfo m1, MethodInfo m2)
    {
      // FIXME: handle ref/out parameters and generic arguments restrictions

      if (m1.Name != m2.Name || m1.ReturnType != m2.ReturnType)
        return false;

      if (!m1.IsGenericMethod)
      {
        var parameterTypes1 = m1.GetParameters().Select(p => p.ParameterType);
        var parameterTypes2 = m2.GetParameters().Select(p => p.ParameterType);

        return parameterTypes1.SequenceEqual(parameterTypes2);
      }

      return true;
    }
  }
}

Para generar el proxy usamos el método ProxyGenerator.CreateInterfaceProxyWithoutTarget, que crea un proxy que implementa el interfaz especificado y no tiene un objeto detrás, por lo que toda la implementación que queramos hacer tendremos que hacerla mediante interceptores.

Ahí entra en juego la clase DuckTypingInterceptor, que es el interceptor que se va a encargar de redigir las llamadas al objeto sobre el que estamos aplicando el duck typing. Cuando se intercepta una llamada, se busca un método en el objeto que estamos adaptando que tenga la misma signatura que el método invocado, y se redirige a ese método la llamada.

Conclusiones

Como decía al principio del post, el duck typing es una característica bastante interesante que a veces se echa de menos en lenguajes estáticos. Es verdad que al aplicarlo con técnicas como las descritas en este post se pierden partes de las ventajas de un lenguaje estático, fundamentalmente la detección de errores en tiempo de compilación, pero a cambio ganamos una flexibilidad que puede ser útil en determinados casos.

Uno podría pensar que el uso de dynamic y ExpandoObject en C#4 permite hacer esto de forma más sencilla, pero lo cierto es que no he visto una forma de sacarle partido porque aunque podemos pasar el objeto declarado como dynamic como si fuese cualquier interface, lo único que obtendremos será un RuntimeBinderException.

La implementación es muy mejorable y tiene varios fallos, como que no gestiona parámetros ref/out o fallaría si hay sobrecargas de métodos genéricos, pero sirve como prueba de concepto y es fácil para trastear con ella. Podéis encontrar el código completo con algún test más demostrando cómo funciona en este gist.

Si alguien le quiere echar un ojo a librerías más completas (y complejas) para hacer esto, puede empezar por impromptu o clay, que tienen buena pinta.