Introducción a los lenguajes dinámicos con C# 4.0 y sus aplicaciones

2008-11-27T19:19:57Z

Los lenguajes dinámicos, en pocas palabras, son la neta. Mi entusiasmo a este tipo de programación siempre ha sido evidente por el poder que representa para el programador. De ahí mi gusto siempre desenfrenado por Visual Basic, dada su implementación rudimentaria de dinamismo (el famoso late binding) y las cosas que podíamos hacer con COM desde épocas inmemorables, ya platicaremos en un momento más al respecto de ésto.

Pero vamos por partes.

En este artículo aprenderemos que son y para qué sirven estos lenguajes y trato de explicar muchos conceptos básicos (y quizá alguno no tan básico) sobre ella, además de ver la implementación ya posible con C# 4.0

Espero que este artículo sea del gusto de todos ustedes y que sirva como punto de inicio para prepararnos (o reencontrarnos) con las delicias de la programación dinámica.

Antecedentes:

Anders Helsberg anunció C# 4.0 en el PDC 2008, C# 4.0 representa un paso más en la evolución de C#. Los milestones, o las características principales de C# son los siguientes

· C#1.0: La primera versión de nuestro querido lenguaje de programación creado específicamente para la plataforma .NET

· C#2.0: Más funcionalidad con tipos de datos genéricos, tipos anulables, métodos anónimos y algunas otras delicias sintácticas

· C# 3.0: Inicializadores de objetos, expresiones lambda, árboles de expresiones, métodos de extensión entre otras cosas, todo esto para lograr desde luego el soporte a LINQ.

· C#4.0: Programación dinámica y quizás la posibilidad de compilador como servicio (quizás porque Microsoft no ha anunciado nada hasta el momento, quizás sea parte de C#4.0 o quizás tengamos que esperar hasta la siguiente versión)

Así que lo más destacado de la versión 4.0 de C# es la posibilidad de manejar tipos dinámicos, lo cual explicaremos a continuación

¿Qué es un lenguaje dinámico?

Un lenguaje dinámico, en pocas palabras es un lenguaje que en tiempo de ejecución realiza cosas que tradicionalmente se harían en tiempo de compilación. Entre estas cosas tenemos:

1) Parseo (Análisis) de expresiones: Es poder enviar al lenguaje generalmente una cadena y que el tiempo de ejecución lo interprete como código ejecutable en el acto. Si les viene a la mente la función Eval() de Javascript, están en lo cierto, es exactamente eso.

2) Verificación de tipos de datos. Si en C# tratamos de sumar perros, con enteros, con cadenas y con gatos, el compilador nativamente nos daría un error en tiempo de compilación la mayoría de las veces (digo la mayoría porque en tiempos de las primeras versiones de C# cuando no había tipos genéricos podíamos hacer operaciones de este tipo y recibir el tronido hasta que el programa ya estaba corriendo juar juar). Con un lenguaje dinámico podemos definir las reglas para manejar tipos de datos heterogéneos. Además es posible hacer el binding de un objeto a una variable

3) Redefinición y alteración a los tipos: En los lenguajes tradicionales (no dinámicos) una vez que hemos definido un tipo es imposible cambiarlo. Sí sí claro algunos de ustedes dirán que no es necesario toda vez que puedo definir contratos mediante interfaces y clases abstractas y meter cualquier tipo de información en estas plantillas y así ya queda, pero recordemos: Las interfaces y las clases abstractas no son en runtime, es decir, no puedo alterar el contrato una vez definido, además de que debo escribir una gran bola de código para definir estas estructuras. Lenguajes como Phyton o Ruby permiten nativamente esto, y C# 4.0 también, como lo veremos en éste artículo

4) Emisión de bloques ejecutables: Esto se refiere a código que genera código. Se implementa mediante closures y funciones de orden superior, esto es parcialmente posible en C# mediante funciones de orden superior y expresiones lambda (ver más en mi artículo publicado en la revista Software Gurú)

¿Y para qué sirve todo esto? Los lenguajes dinámicos facilitan enormemente la labor del programador haciéndolo más productivo, ayudándolo entre otras cosas con:

· Permiten la carga de tipos de datos desde estructuras externas (como por ejemplo un archivo en XML o en JSON) y usar sintaxis nativa de atributo para asignar o leer información

· Permiten usar datos sin necesidad de definir contratos (las interfaces, precisamente son el paliativo de la estaticidad de C#)

· Fomentan el bajo acoplamiento (No tengo que tener referencias a bibiliotecas de tipo, que si cambian, me hacen recompilar el código)

· Eliminan las bibliotecas de tipos y/o intefaces

· Eliminan las referencias circulares (molesto y horrible dolor de cabeza)

· Disminuyen la cantidad de código requerido

· Evalúan en tiempo real fórmulas y código (por ejemplo para los molestos cálculos de nómina, dado que las leyes fiscales cambian constantemente)

· Facilitan la creación de alfabetos finitos con significado para nuestro programa

· Modifican el comportamiento de un proceso o flujo de trabajo en tiempo real sin necesidad de recompilar

· Dan la posibilidad de generar un “polimorfismo extremo” dirigido por los datos, esto es, permiten que un tipo de datos mute (o sea que se le agregue comportamiento o estado en tiempo de ejecución) en cualquier momento

· Facilitan la metaprogramación, es decir código que genera o manipula código, por ejemplo yo podría permitirle a un usuario describir como es un tipo de dato y en tiempo de ejecucución tener un programa que manipule o lea esa información

Como podrán ver son bastantes las ventajas y puedo seguir echando choro acerca de todo lo que se puede hacer con un lenguaje dinámico, pero también hay que decirlo, también tienen sus desventajas como exponer nuestro programa a errores en tiempo de ejecución, herramientas de programación más pobres (adiós Intellisense), menor desempeño en la aplicación por la chamba adicional que le damos a la computadora de inferir y hacer casts en tiempo de ejecución. Hay que poner en la balanza si estos problemas no superan al beneficio de usar los lenguajes dinámicos.

Existen diferentes implementaciones de dinamismo en lenguajes como Ruby, Phyton y hasta el mismo Visual Basic y COM con su capacidad para hacer late binding, sin embargo aquí nos concentraremos en aprender cómo funcionarán estos conceptos en C#.

La línea de un lenguaje de programación estático y dinámico no es muy clara, los lenguajes estáticos (el CLR de .NET en general) fue creado para ser fuertemente tipado, sin embargo tiene alternativas para generar “cierto” dinamismo. La herramienta principal de .NET para esto es la reflección (Reflection) en el namespace System.Reflection. Este namespace contiene clases para conocer en tiempo de ejecución los tipos de datos, es más, es posible generar métodos dinámicos escribiendo directamente los opcodes del IL (Intermediate Language), sin embargo esto es sumamente complejo de lograr toda vez que tendríamos que aprender IL además de existir muchas limitantes, lo que trato de decir es que no creo que haya un lenguaje totalmente dinámico ni otro totalmente estático, cada lenguaje tiene su propia implementación en mayor o menor medida para realizar las tareas que enumeré en párrafos anteriores.

Un poco de historia en la plataforma Microsoft sobre los tipos dinámicos

Como escribí en los renglones superiores, esto de no ser tan estricto en la tipificación de los datos no es nuevo en la plataforma Microsoft.

Quienes programamos alguna vez con COM o con Visual Basic 6.0 recordaremos código como el siguiente:

'VB 6.0/VBScript

Dim lobjUnObjeto

Set lobjUnObjeto = CreateObject("ADODB.Connection")

Lo que sucede con el código anterior es que la función CreateObject devuelve una referencia a un objeto COM. Todo objeto COM debe tener implementada la interface IDispatch (que a su vez hereda de IUknown y que son las interfaces básicas para hacer que un objeto tenga la capacidad de utilizarse en COM) Veremos en un rato cómo se parece el modelo a lo que actualmente (o próximamente) tendremos en C#.

Una vez que utilizábamos una sintaxis semejante a la anterior podíamos fácilmente mandar a llamar a cualquier método o atributo con la sintaxis del puntito

lobjUnObjeto.Metodo1

lobjUnObjeto.Atributo1

Tener una situación similar en C# 3.0 o anteriores es imposible, toda vez que siempre es necesario agregar una referencia a y en tiempo de compilación conocer previamente el tipo de datos para poder hacer cualquier llamada a un método o atributo.

Pues que creen... En C# 4.0 YA ES POSIBLE OTRA VEZ jeje. De hecho éste artículo el artículo se iba a llamar “Y Visual Basic siempre tuvo razón”, pero seguramente iba a herir varias susceptibilidades, así que le cambié el nombre. Fuera de coto, la posibilidad de utilizar sintaxis dinámica en C#, desde mi humilde punto de vista hace a C# un lenguaje de programación multiparadigma real, con capacidad para utilizar el paradigma estructurado, orientado a objetos, funcional y dinámico. Esto es una excelente noticia para todos nosotros que día a día nos enfrentamos a pantallas llenas de código en C#.

Algo que me gustaría aclarar es que el código fuertemente tipeado debe de prevalecer, el hecho de que C# tenga estas nuevas funcionalidades no significa que debemos olvidar todo lo que hemos aprendido hasta el momento sobre las buenas prácticas de la programación orientada a objetos y componentizada (interfaces, contratos, mecanismos de publicación – suscripción etc.), yo creo que como deberíamos de ver estas alternativas exactamente como eso, simplemente como una serie de alternativas que nos darán mayor productividad y facilidad al programar, pero no debemos de perder el foco y caer en el libertinaje haciendo código dinámico y olvidar de plano la tipificación.

Todo se resume en una máxima: Usemos siempre fuerte tipificación, a menos de que sea absolutamente necesario, usemos tipos dinámicos.

Basta pues de todo esto y concentrémonos ahora en ver la implementación básica de dinamismo en C# 4.0.

El tipo de datos dynamic

C# 4.0 introduce el tipo de datos dynamic, que no es más que una manera alternativa de decirle al compilador que NO verifique el tipo de datos en tiempo de ejecución. Según los arquitectos de C# la palabra dynamic representa un objeto estáticamente tipado para ser dinámico.

El código se ve así:

   1: //C# 4.0

   2: dynamic variable = 1;

En pocas palabras, y sin tanto choro, lo que sucede es que estamos declarando un objeto del tipo objeto pero como mencionamos esta implementación permite dejar la verificación del tipo (el binding) hasta el tiempo de ejecución

¿Ustedes dirán y eso no es lo mismo que var? La respuesta es ¡No!, son dos cosas completamente diferentes, veamos el siguiente ejemplo

   1: //C# 4.0

   2: dynamic objeto = 1;

   3: var objeto2 = 1;

En la línea 2, internamente lo que sucede es que se asigna el tipo de datos objeto el cual se conocerá hasta el runtime y en la línea 3 quien infiere el tipo de datos es el compilador y antes de ejecutarlo se conoce el tipo, por lo que sigue siendo un tipeado estático.

Internamente esta funcionalidad se monta sobre una pieza de software que ya tiene un ratito entre nosotros que es el DLR.

El DLR

El DLR o Dynamic Language Runtime que se monta sobre el CLR, es decir, no lo reemplaza ni mucho menos, es simplemente código adicional que sirve para facilitarnos la vida a la hora de hacer las cosas dinámicas. Físicamente vive en un ensamblado llamado Microsoft.Scripting y proporciona clases que facilitan en gran medida la utilización de lenguajes dinámicos.

El DLR tiene como funcionlidad proveer funciones básicas de dinamismo, de la misma manera que en COM y VB 6.0 lo hacía la interface IDispatch y la función CreateObject, sin embargo y a diferencia de COM, el CLR tiene funciones de optimización para hacer que el código sea mucho más eficiente, toda vez que tiene soporte para caché de objetos, además de permitir la interoperabilidad de diferentes lenguajes de programación dinámicos como IronPython o IronRuby.

Vayamos ahora a aplicaciones reales de esta tecnología

Bajo acoplamiento con C# 4.0

Como lo he mencionado creo que en la mayoría de los posts que he hecho, es básico y conocido por todos que debemos fomentar la ya veterana la programación basada en componentes, al menos en tres capas, capa de usuario, regla de negocio y capa de persistencia o acceso a base de datos. Generalmente hay una dependencia de composición o agregación entre dichas capas, o sea agregamos una referencia desde la capa de usuario para que vea a los tipos y funciones de la Regla de Negocio y a su vez esta tiene una referencia a la capa de datos.

El problema con C# es que si queremos seguir un modelo semejante en C#, además debemos definir bibliotecas de interfaces para que la capa de datos conozca las entidades porque las entidades (clases especializadas en la persistencia de datos) generalmente deben persistir en una regla de negocio, o bien en el caso de que queramos realizar inyección de dependencias sucede exactamente lo mismo.

El tipo de datos dynamic permite una manera sencilla de hacer esto aun mas simple de lo que ya es. Veamos como

Lo primero que vemos es la capa de usuario (en este caso una vil formita con dos botones), uno que acumula datos en un diccionario y el otro que invoca a la Regla de negocio con la cual tiene dependencia, éste código es perfectamente legal en C# 3.0 porque no hay nada nuevo y aun no usamos la palabra clave dynamic. Examinemos pues el código

   1: ///C# 4.0///////////CAPA DE USUARIO//////////////////////////

   2: using System;

   3: using System.Collections.Generic;

   4: using System.ComponentModel;

   5: using System.Data;

   6: using System.Drawing;

   7: using System.Linq;

   8: using System.Text;

   9: using System.Windows.Forms;

  10: using Rdn.Entidades;

11:

  12: namespace Usr

  13: {

  14:     public partial class Form1 : Form

  15:     {

  16:         //Aqui guardare los datos de las personas

  17:         List<Persona> Personas = new List<Persona>();

18:

  19:         //PASO 1-------------------------------------------------------------------------

  20:         //Este botón lo único que hace es agregar entidades persona al diccionario Personas

  21:         private void button1_Click(object sender, EventArgs e)

  22:         {

  23:           //Invoco a la entidad Persona de regla de negocio (Rdn) y la lleno

  24:             Rdn.Entidades.Persona unaPersona = new Rdn.Entidades.Persona() {

  25:                 Id=Personas.Count+1, AMaterno="Perez", APaterno="Perez", Nombre="Lucha" };

  26:           //Sólo agrego la entidad al diccionario

  27:             Personas.Add(unaPersona);

  28:         }

29:

  30:         //PASO 2 -------------------------------------------------------------------------

  31:         //Aquí doy clic cuando termino de agregar personas al diccionario

  32:         private void button2_Click(object sender, EventArgs e)

  33:         {

  34:             //Instancio la Rdn

  35:             var ReglaNegocio = new Rdn.Rdn();

  36:             //Invoco el método de la Rdn y le paso el diccionario lleno de Personas

  37:             ReglaNegocio.AgregarPersonas(Personas);

38:

  39:         }

40:

41:

  42:         public Form1()

  43:         {

  44:             InitializeComponent();

  45:         }

46:

  47:     }

  48: }

Posteriormente veremos lo que hay en la RDN. En este caso y para hacer menos verboso el código esta RDN realmente no hace nada (recordemos que las capas de negocio tienen como función principal la orquestacíón de los procesos), sino que le avienta el diccionario a la capa de acceso a datos (persistencia). Igual que en el código anterior, éste código NO tiene nada novedoso.

   1: //C# 4.0 ////////////////////CAPA DE REGLA DE NEGOCIO

   2: using System;

   3: using System.Collections.Generic;

   4: using System.Linq;

   5: using System.Text;

6:

   7: namespace Rdn

   8: {

   9:     public class Rdn

  10:     {

  11:         public void AgregarPersonas(List<Entidades.Persona> pobjPersonas)

  12:         {

  13:             //Instancio a la capa de persistencia y le paso el mismo objeto recibido

  14:             var BaseDatos = new Abd.Abd();

  15:             BaseDatos.Persistir(pobjPersonas);

16:

  17:         }

  18:     }

  19: }

Aquí tienen la definición de la clase Persona

   1: namespace Rdn.Entidades

   2: {

3:

   4:     public class Persona

   5:     {

   6:       public int Id;

   7:       public string APaterno;

   8:       public string AMaterno;

   9:       public string Nombre;

  10:       public string Telefono;

11:

  12:     }

  13: }

Por fin llegó el momento de utilizar la palabra clave dynamic. La usaremos en este ejemplo precisamente en la capa de persistencia.

   1: //C# 4.0 CAPA DE ACCESO A DATOS CON dynamic

   2: using System;

   3: using System.Collections.Generic;

   4: using System.Linq;

   5: using System.Text;

   6: using System.Windows.Forms;

   7: using System.Diagnostics;

8:

   9: namespace Abd

  10: {

  11:     public class Abd

  12:     {

  13:         //Recibo la entidad persona, pero como podemos ver NO CONOZCO EL TIPO!!!

  14:         //sólo lo declaro como dynamic y el código es completamente válido

  15:         public void Persistir(dynamic pdynObjeto)

  16:         {

17:

  18:             foreach (dynamic Item in pdynObjeto)

  19:             {

  20:                 //Aqui se pone el código para persistir en bdd, en este

  21:                // ejemplo solo lo mando a la ventana de debug

  22:                 Debug.Write(Item.APaterno + " "  + Item.AMaterno+ " " +Item.Nombre);

  23:                 Debug.Write(Item.Id.ToString());

24:

  25:             }

26:

  27:         }

28:

  29:     }

  30: }

Como podemos ver no tuve que hacer interfaces, ni bibliotecas de tipos. El compilador permite la compilación sin ningún problema y descubre en tiempo de ejecución las propiedades (en teste caso APaterno, AMaterno etc, de los datos que le llegan.) jaja al más puro estilo de VB 6.0. Quiero señalar que en un contexto controlado esta implementación no es la óptima, sin embargo, es útil cuando queremos implementar arquitecturas dirigidas por los datos.

¿Qué más se puede hacer con C# 4.0?

Generación de atributos dinámicos en tiempo de ejecución.

Examinemos el siguiente código válido en C# 4.0, creo que habla por sí solo...

   1: //C# 4.0

   2: private void button3_Click(object sender, EventArgs e)

   3:        {

   4:            //Creo un diccionario de atributos que se agregarán dinámicamente

   5:            //en tiempo de ejecución a una clase que se llama PerroDinamico

   6:            Dictionary<string, object> AtributosDinamicos = new Dictionary<string, object>();

   7:            AtributosDinamicos.Add("Color", "Verde");

   8:            AtributosDinamicos.Add("Raza", "Chihuahua");

   9:            AtributosDinamicos.Add("Edad", 7);

  10:            //Defino tipo dinámico

  11:            dynamic UnPerroDinamico = new PerroDinamico(AtributosDinamicos);

  12:            //Invoco a los atributos con sintaxis estándar de atributo

  13:            //como si 'realmente' existieran, cosa que no se podía hacer antes

  14:            //porque este código hubiera lanzado una excepción

  15:            MessageBox.Show(UnPerroDinamico.Raza);

  16:            MessageBox.Show(UnPerroDinamico.Edad.ToString());

17:

  18:        }

El msgbox evidentemente muestra "Chihuahua" y 7. Esta clase llamada PerroDinamico hereda de.

Veamos su implementación:

   //C# 4.0

   1: public class PerroDinamico : System.Scripting.Actions.Dynamic
 //Clase con la interface IDynamicObject implementada

   2:     {

   3:         Dictionary<string, object> DiccionarioAtributos= new Dictionary<string,object>();

   4: //Recibo el diccionario con los atributos

   5:         public PerroDinamico(Dictionary<string, object> pAtributos)

   6:         {

   7:             DiccionarioAtributos = pAtributos;

   8:         }

9:

  10:         public PerroDinamico()

  11:         {

  12:             throw new NotImplementedException();

  13:         }

14:

  15: //Estos métodos proveen la implementación de los atributos dinámicos, en este caso

  16: //no se realiza implementación adicional

  17:         public override object GetMember(GetMemberAction action)

  18:         {

19:

  20:             return DiccionarioAtributos[action.Name];

21:

  22:         }

23:

  24:         public override void SetMember(SetMemberAction action, object value)

  25:         {

26:

  27:             DiccionarioAtributos[action.Name] = value.ToString();

28:

  29:         }

30:

31:

  32:         }

Con esto podemos comprobar que el dinamismo con el DLR de .NET es bastante poderoso, toda vez que es posible implementar cualquier tipo en forma dinámica, y compartir la implentación independientemente del lenguaje.

Como conclusión puedo decir que estoy muy emocionado con todo esto, nos permitirá hacer cosas que antes eran, si no imposibles, muy talachudas de hacer y de nuevo, los invito a que cuando esto salga no lo usemos en demasía, solamente para cuando sea estrictamente necesario.

Pues a grandes rasgos esta fue una explicación somera del funcionamiento del dinamismo en C#. Espero que les haya gustado, cualquier duda o comentario no duden en externarlo poniendo un reply.

Gracias y los invito a que vean esto, es la entrevista de Anders Helsberg sobre las motivaciones que llevaron al equipo de C# a implementar estas cosas, se las recomiendo especialmente a los que no están muy convencidos de esta nueva flexibilidad:

mms://mschnlnine.wmod.llnwd.net/a1809/d1/ch9/4/2/3/2/4/4/CSharpFourQuestionsAndReasons_s_ch9.wmv

Un abrazo a tod@s y ¡Feliz Codificación!

Miguel Angel Morán

Introducción a los lenguajes dinámicos con C# 4.0 y sus aplicaciones

Asiste al Evento de lanzamiento Comunidad del DF