Activator, crear objetos a partir de texto

Hace algunos años, en uno de los primeros articulos que escribí en devjoker - pulsa aqui para ver el artículo original - explicabamos la forma de crear instancias de un objeto a partir de un string con C#, algo que habia implementado con gran exito en proyecto Java anterior.

Para ello definiamos un interfaz, utilizamos el dominio de aplicacion actual para obtener un objeto con AppDomain.CurrentDomain.CreateInstance y posteriomente convertiamos y ejecutamos la interfaz. Muy al estilo del patrón de diseño Factory Method basado en interface,.

Lo que es la ignorancia - por aquellos tiempos andaba aprendiendo esto del .NET -, y es que el framework posee una clase especializa en realizar esta tarea. La clase Activator.

En este ejemplo vamos a hacer otra implementacion del patron de diseños factoria, pero está vez en lugar utilizar un interface vamos a utilizar una clase abstracta. Definimos una clase abstracta ProveedorPadre, y las clase que hereden de esta deben sobreescribir el método HacerAlgo<T> ¡más generico no se puede!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ActivatorSample
{
class Program
{
static void Main(string[] args)
{
string typename = "OtroNamespace.Proveedor1";
if (args.Length > 0)
{
typename = args[0];
}
ProcessType( typename);
Console.ReadLine();
}

private static void ProcessType(string typename)
{
Type tipo = Type.GetType(typename);
if (typeof(ProveedorPadre).IsAssignableFrom(tipo))
{
ProveedorPadre director =
(ProveedorPadre)Activator.CreateInstance(tipo);
director.HacerAlgo<int>(1);
director.HacerAlgo<string>("parametros");
director.HacerAlgo<DateTime>(DateTime.Now);
}
else {
throw new
InvalidOperationException("No implementa ProveedorPadre");
}

}
}

public abstract class ProveedorPadre
{
public abstract void HacerAlgo<T>(T indata);
}

}

namespace OtroNamespace
{
public class Proveedor1 : ActivatorSample.ProveedorPadre
{
public override void HacerAlgo<T>(T indata)
{
Console.WriteLine(
"Se ha recibido en Proveedor 1 el dato: {0}",indata.ToString());
}
}

public class Proveedor2
{
public Proveedor2()
{
//Sencillamente no hereda de ProveedorPadre!
}
}
}

En este ejemplo hemos incluido una segunda clase Proveedor2 que no hereda de nuestra clase abstracta, para controlar el posible error. Si invocamos al programa y enviamos por parametro "OtroNamespace.Proveedor2" obtendremos una excepcion de tipo InvalidOperationException.

La pregunta ahora es inmediata ... ¿que método es mejor y cual debo utilizar? ... pues lo mismo dá porque AppDomain.CurrentDomain.CreateInstance lo que hace internamente es invocar a la clase Activator.

Si analizamos la clase Activator con .NET Reflector podemos observar su implementación:

public System.Runtime.Remoting.ObjectHandle
CreateInstance(string assemblyName, string typeName)
{
if (this == null)
{
throw new NullReferenceException();
}
if (assemblyName == null)
{
throw new ArgumentNullException("assemblyName");
}
return Activator.CreateInstance(assemblyName, typeName);
}

Saludos, DJK

Versión para imprimir

Foros de consulta

sí<> por Mihai Mosor
Respuesta recibida el [29/10/2009 04:53:20]

Sí, más generico ni que puede ser. La verdad es que la implementación de las clases abstractas son muy útiles, en especial cuando se trata de actualizar un programa, algo parecido al estilo Windows, eso sí, genericos y clases de herencia. 
Muy bueno, este capítulo no lo había tocado hasta ahora, gracias por haberlo publicado. 
Saludos();

La gracia de esto es la creaci... por UnoDePorAhí
Respuesta recibida el [02/11/2009 09:24:57]

La gracia de esto es la creación de objetos dinámicamente en tiempo de ejecución... ya que no hay que declarar el tipo de objeto explícitamente... aunque también se puede usar reflection.
Buen artículo