Genericidad en vez de typeof

Permítame un breve descanso entre tantos disparates. He estado usando últimamente una técnica sencilla y conocida para identificar posibilidades de simplificación en código heredado de .NET v1.1. La técnica consiste en buscar métodos, en el código fuente, que reciban un parámetro de tipo System.Type, para considerar la posibilidad de convertir dicho método en un método genérico.

El caso típico se encuentra casi siempre en el "gestor" de ventanas:

public interface IFormManager
{
    Form ShowForm(Type formType);
}

ShowForm recibe un tipo de ventana como parámetro, y debe encontrar una ventana abierta cuyo tipo sea exactamente el especificado. Si la encuentra, debe activarla y pasarla a primer plano. En caso contrario, debe crear una ventana de este tipo, y mostrarla. La regla que he mencionado establece que el método anterior debería transformarse en algo parecido a lo siguiente:

public interface IFormManager
{
    T ShowForm<T>()
        where T: Form, new();
}

Puntos a destacar:

1. El parámetro de tipo T se ha restringido de dos maneras. En primer lugar, debe ser una clase descendiente de Form. Usted, naturalmente, puede exigir de sus ventanas que desciendan de alguna clase más concreta, o que implementen algún tipo de interfaz general, o ambas cosas a la vez.
2. Por otra parte, he exigido que las ventanas tengan un constructor sin parámetros. Este es un requisito opcional, que no valdrá en todos los casos, pero que he incluido aquí para simplificar un poco el código.
3. Observe que será imposible, al utilizar este método, que el compilador pueda "inferir" el parámetro de tipo. Si no ha trabajado aún con la inferencia de tipos en llamadas a métodos genéricos, traduzca la oración anterior así: "siempre tendremos que indicar explícitamente el tipo de ventana" (algo bastante razonable).

¿Qué hemos ganado con esta transformación? Antes, para mostrar una ventana, teníamos que escribir código como el siguiente:

// "manager" implementa "IFormManager"
MiVentana v = manager.ShowForm(
    typeof(MiVentana)) as MiVentana;

Si no efectuamos la conversión de tipos, obtendremos como resultado un valor de tipo Form, sin más adornos. En cambio, con la versión genérica obtendremos el tipo originalmente deseado:

MiVentana v = manager.ShowForm<MiVentana>();

Para cerrar el círculo, le mostraré una sencilla implementación inicial del tipo de interfaz:

public class FormManager : IFormManager
{
    private List<Form> forms = new List<Form>();
 
    public T ShowForm<T>()
        where T: Form, new()
    {
        foreach (var f in forms)
            if (f.GetType() == typeof(T))
            {
                f.Show();
                f.BringToFront();
                return f as T;
            }
        var frm = new T() { Visible = true };
        frm.FormClosed += (sender, e) =>
            forms.Remove((Form)sender);
        forms.Add(frm);
        return frm;
    }
}

Creo que la primera parte, la que ejecuta el bucle, es fácil de comprender. Luego he complicado un poco las cosas: observe que puedo ejecutar el constructor sin parámetros del tipo T gracias a las restricciones establecidas sobre el parámetro genérico. Si mis ventanas no se pudiesen construir de esa manera, sino que requiriesen parámetros, entonces tendría que utilizar un poco de reflexión. Tenga presente, no obstante, que la ejecución de un constructor sin parámetros sobre un parámetro de tipo genérico es implementada por el compilador como una llamada al API de reflexión (lo sé porque Freya hace exactamente lo mismo).

¿Ve esas llaves tras la llamada al constructor? Se trata simplemente de una asignación a la propiedad Visible del formulario recién creado. Podía haberla sustituido por una llamada al método Show, pero quise mostrar un ejemplo de inicialización de objetos. Luego, resolvemos un problema más serio: FormManager lleva una lista de las ventanas abiertas (o abiertas e invisibles). Las ventanas se añaden al ser creadas, pero ¿cuándo se eliminan de esta lista? Para ello, asociamos un manejador al evento FormClosing de cada nueva ventana. En vez de crear el manejador como un método independiente, he preferido utilizar una expresión lambda.

---

Comentarios adicionales: ¿para qué hace falta una interfaz IFormManager? ¿No sería más sencillo diseñar ShowForm como un método estático, dentro de una clase estática? La clave del uso de IFormManager está en la posibilidad de usar diferentes implementaciones según nos convenga. La manía de recurrir a métodos estáticos a la primera es una manifestación de lo que yo llamo "la fiebre del singleton". Es cierto que, al final, nuestro gestor de ventana tendrá que proveer algún singleton, como la variable "manager" de mi ejemplo de uso. Pero la aparición del singleton debe retrasarse todo lo que podamos.