Aplicación Pomodoro en C# Mobile 6.5 – Cómo el singleton ha cambiado la arquitectura de la aplicación

Dándole vueltas al tema de los delegados, eventos y suscriptores, me día cuenta que me venía ni pintado utilizar el patrón singleton para instanciar una y solo una vez los tres o cuatro formularios de la aplicación y así poder suscribir el método del combo de tareas a realizar a todos los eventos de los diferentes formularios.

Este “ligero” cambio, literalmente, me dio la vuelta a toda la arquitectura de la aplicación ya que inmediatamente saltó a la vista que no necesitaba eventos, al poder crear un método público al cual invocar donde y cuando quisiera en el resto de la aplicación y, sorpresa, a costa de memoria la aplicación se volvió rapidísima.

Después de una par de horas revisando pros y contras y dándole vueltas a la cabeza decidí olvidar los eventos y los delegados e irme por el camino del método público ya que tiene un nivel de acoplamiento menor y se visualiza mejor en el intellisense.

Lo primero es hacer el código de instanciación Singleton de los tres formularios de la aplicación. Para refrescar la memoria os cuento que este patrón se utiliza cuando necesitas que un objeto se instancie solamente una vez, como es este el caso.

Lo primero es hacerme una clase llamada formularios, que será la que me realice la instancia de los diferentes formularios. Y cortarle la creación de la clase por defecto haciendo el método protected. (ya no puedo hacer un formulario = new formulario();).

public class formularios
    {
        protected formularios() { }
    }

A continuación le creo una variable privada estática del tipo de la propia clase igualada a nulo, que será la que utilice para saber si la clase formulario está instanciada o no.

        private static formularios instancia = null;

¿Para qué, te preguntarás? Pues para cuando desde fuera se consulte  a la propiedad pública estática del tipo de la clase formularios que devuelva una instancia de la misma, en el método get de la propiedad consulte a la variable y si está nula que cree un nuevo objeto o si no que devuelva siempre la instancia ya creada anteriormente.

        public static formularios Instancia
        {
            get
            {
                if (instancia == null)
                    instancia = new formularios();

                return instancia;
            }

        }

Fale, muy bonito. Pero dónde creo los formularios… pues a continuación.

        public Pomodoro Pomodoro = new Pomodoro();
        public Inventory Inventory = new Inventory();
        public ToDoToday ToDoToday = new ToDoToday();

Quedando el código de la siguiente manera:

    ///

    /// Instancia los formularios de la aplicación.
    /// Utilizo el patrón singleton para evitar que me instancie cada vez formularios diferentes.
    ///
    public class formularios
    {
        private static formularios instancia = null;
        protected formularios() { }
        public static formularios Instancia
        {
            get
            {
                if (instancia == null)
                    instancia = new formularios();
                return instancia;
            }
        }
        public Pomodoro Pomodoro = new Pomodoro();
        public Inventory Inventory = new Inventory();
        public ToDoToday ToDoToday = new ToDoToday();
    }

Así, por ejemplo, para navegar de un formulario a otro simplemente lo invoco a la instancia única de la clase formulario. Lo cual me da MUCHA velocidad:

formularios.Instancia.Pomodoro.Show();



Y para llamar a un método público del formulario principal desde cualquier otro formulario lo invoco asi:

formularios.Instancia.Pomodoro.recargaComboToDo();



N.A. Este código tiene un fallo perverso que debo de refactorizar con calma para ver de eliminarlo. Y es que un futuro desarrollador puede realizar las llamadas directas a los constructores públicos de los formularios y reventar todo el flujo de la aplicación. Asíque debo buscar la forma de impedir que se pueda acceder a estos constructores a menos que sea desde esta clase “formularios”.

Ya os iré contando.