Las visitas, a fin de cuentas, alimentan el ego, y por aquel entonces, ese sabor proporcionaba una impostada sensación de importancia en un mundo que se estaba volviendo digital. A día de hoy leo aquellas entradas con ternura, ya que soy consciente de que no tengo ni idea sobre nada, y que todos los días hay algo sobre lo que aprender.

A medida de que mi carrera fue virando (abandoné el desarrollo en .NET y me pasé a la calidad del software), mi motivación por compartir información que más o menos dominaba fue decreciendo, ya que la sensación de seguridad que te ofrece creer que dominas una materia se fue desvaneciendo. Si unimos todo eso a la formación de una familia, es fácil imaginarse que mantener el blog pasó a un completo segundo plano.

En cualquier caso, hace poco decidí volver a retomar mi pequeño espacio personal, pero desde otro enfoque distinto. No creo que retome .NET (si bien lo he seguido usando en proyectos internos, me he quedado demasiado descolgado como para poder «enseñar» nada), así que he decidido hacer borrón y cuenta nueva, dejando https://danielggarcia.wordpress.com tal y como se concibió incialmente. Si te suscribiste o seguiste mi blog: mil gracias por tu atención. No obstante, entiendo que si seguiste a mi antiguo yo fue porque te interesaba .NET y el desarrollo. Y debido a que esta nueva etapa pretende ser más personal y enfocada en otras materias, no me parece justo «arrastrar» a mis suscriptores a temas que probablemente no les interesen.

Gracias por todo.

Nos vemos en danigarcia.org.

Para llegar a ser grande necesitarás, al menos a tres tipos de personas: alguien mejor de quien poder aprender, alguien inferior a quien poder enseñar y alguien igual con quien poder medirse.

Frank Shamrock

Sin embargo, I’ll be back. No soy persona que guste de dejar las cosas a medias, y en cuanto saque un poco de tiempo, me pondré manos a la obra para finalizar los patrones que quedan pendientes y seguir dando guerra por estos lares.

Por lo tanto, ante la pregunta de que si publicaré más patrones, la respuesta es «sí». Lo que no puedo asegurar es cuándo. Pero intentaré que no sea muy tarde.

Y por supuesto, agradezco vuestras críticas y vuestros comentarios.

Nos vemos pronto.

«Definir una dependencia uno-a-muchos entre objetos de forma de que, cuando el estado de uno de ellos cambia, todos los objetos dependientes son notificados y actualizados de forma automática».

Design Patterns: Elements of Reusable Object-Oriented Software

Podemos afirmar sin rubor alguno que el patrón Observer es uno de los más importantes (y utilizados) de todos los patrones de diseño vistos hasta el momento. Su filosofía es simple: un objeto, denominado sujeto (Subject) posee un estado. Cuando su estado cambia, es capaz de «avisar» a sus subcriptores (Observers) de este cambio de estado. De este modo, los objetos suscritos al objeto no tienen que preocuparse de cuándo se produce un cambio de estado: éste se encargará de informar de forma activa a todos aquellos objetos que hayan decidido suscribirse.

Este tipo de suscripción puede ser de dos tipos:

• Suscripción push: el objeto informa a sus suscriptores con sus valores tan pronto como su estado cambie.
• Suscripción pull: el objeto es interrogado por sus suscriptores si su estado ha cambiado desde la última vez que se tanteó.

Este esquema respeta al máximo el principio de bajo acoplamiento. El Subject y el Observer pueden interactuar entre ellos, pero apenas tienen conocimiento del uno sobre el otro. Dado que hemos basado el diseño en abstracciones, no en concreciones, no será necesario modificar el Subject para añadir nuevos Observers (bastará con que implemente la interfaz IObserver). Del mismo modo, un Observer podrá suscribirse a más de un Subject si éste implementa la interfaz ISubject.

Vale, hemos entendido el concepto pero ¿cómo funciona realmente el patrón? Explicado de forma simple, podemos resumirlo de la siguiente manera:

• SubjectConcreto implementa la interfaz ISubject. Esta clase tendrá una funcionalidad propia, un estado (por ejemplo, una serie de variables) y una lista interna de objetos que implementan la interfaz IObserver. Esta lista se utilizará para realizar la «suscripción» a los cambios de estado, invocando el método IObserver.update() de cada objeto dentro de esta lista cada vez que se produzca un cambio de estado. Además, esta clase implementará los métodos de ISubject:
  • registrarObserver(IObserver o): añade el observer «o» pasado como parámetro a la lista de objetos que serán notificados.
  • eliminarObserver(Observer o): elimina el observer «o» pasado como parámetro de la lista de objetos que serán notificados.
  • notificarObservers(): recorre la lista de observers, invocando el método update() de cada uno de ellos, provocando que se realice una acción determinada cuando el estado del Subject cambie. Normalmente este método será invocado en el momento en el que el estado del Subject cambie (por ejemplo, al final del método setState()).

El método update() será implementado por cada Observer concreto, y se encargará de realizar las operaciones que el objeto suscrito quiera realizar cuando se entere de que algo ha cambiado dentro del Subject.

Implementando el patrón Observer

Realizaremos una implementación de este patrón basándonos en un sistema de sensores que realice una medición de los niveles de agua y aceite, así como de la presión de los neumáticos. Este sistema permitirá que los observers puedan suscribirse a los cambios en los valores de estos niveles, realizando las operaciones que estimen oportunas. Comenzaremos creando la interfaz IObserver que incluirá el método update que tendrán que implementar todos aquellas clases que deseen recibir notificaciones. Este método recibirá un parámetro que contendrá información sobre la actualización. Para hacerla lo más genérica posible, haremos que sea de tipo Object, realizando el casting correspondiente a la hora de implementar la clase concreta.

IObserver.cs

    public interface IObserver
    {
        // Metodo que sera invocado por el Subject
        // El objeto "o" seran los valores que el Subject le pasara al Observer
        void update(Object o);
    }

Lo siguiente que haremos sera codificar una interfaz que exponga los métodos propios de un notificador:

• Un método para registrar un observer, que aceptará un IObserver como argumento.
• Un método para eliminar la suscripción de un observer, que también aceptará un IObserver como argumento.
• Un método para realizar la notificación a todos los observers que se encuentren suscritos al Subject.

ISubject.cs

    // Interfaz que expone los metodos de registro y eliminacion de observers, asi como para
    // la notificacion de los cambios de estado.
    public interface ISubject
    {
        void RegistrarObserver(IObserver o);
        void EliminarObserver(IObserver o);
        void NotificarObservers();
    }

A continuación codificaremos el Subject en sí: una clase que implementará la interfaz ISubject y que incluirá los métodos declarados en ésta. Además incluirá una serie de variables que almacenarán los distintos niveles (aceite, agua y presión de los neumáticos) junto a sus respectivas Properties, que permitirán modificar sus valores. En el método set de estas Properties será donde se realice la invocación del método NotificarObservers(), siempre y cuando el valor cambie, es decir, se comprueba si el nuevo valor es igual al anterior, y en caso contrario, se actualiza el estado y se notifica a todos aquellos Observers que se encuentren suscritos. Este método puede afinarse dependiendo del caso concreto (por ejemplo, notificando únicamente cuando el cambio suponga la superación de cierto umbral).

El constructor de la clase recibirá como parámetros los valores iniciales de los niveles de aceite, agua y presión de los neumáticos, además de instanciar el IList que almacenará los Observers suscritos a las notificaciones. Los métodos RegistrarObserver y EliminarObserver serán los encargados de añadir y eliminar suscriptores a la lista (previa comprobación de si éstos están ya en la lista o no). El método NotificarObservers() será tan sencillo como un bucle foreach que recorra todos los IObserver suscritos a las notificaciones, invocando su método update() pasándole el estado del objeto como parámetro.

Previamente hemos dicho que existen dos versiones del patrón:

• Una versión push, que es precisamente la que definimos aquí: el propio Subject inyecta el estado en los Observers, pasándolo como parámetro al método Update().
• Una versión pop, que como alternativa ofrece simplemente informar al Observer que se ha producido un cambio de estado, siendo responsabilidad de éste solicitar al Subject los nuevos valores.

MedidorSensores.cs

    public class MedidorSensores : ISubject
    {
        #region Estado

        // Atributos que modelan el estado
        private int nivelAceite;
        private int nivelAgua;
        private int nivelPresionNeumaticos;

        #endregion

        // Listado de observers
        IList suscriptores;

        #region Properties

        public int NivelAceite
        {
            get { return this.nivelAceite; }

            // Cada vez que se modifique el estado, se invocara el metodo NotificarObservers()
            set
            {
                if (this.nivelAceite != value)
                {
                    this.nivelAceite = value;
                    NotificarObservers();
                }
            }
        }

        public int NivelAgua
        {
            get { return this.nivelAgua; }

            // Cada vez que se modifique el estado, se invocara el metodo NotificarObservers()
            set
            {
                if (this.nivelAgua != value)
                {
                    this.nivelAgua = value;
                    NotificarObservers();
                }
            }
        }

        public int NivelPresionNeumaticos
        {
            get { return this.nivelPresionNeumaticos; }

            // Cada vez que se modifique el estado, se invocara el metodo NotificarObservers()
            set
            {
                if (this.nivelPresionNeumaticos != value)
                {
                    this.nivelPresionNeumaticos = value;
                    NotificarObservers();
                }
            }
        }

        #endregion

        #region Metodos de la interfaz ISubject

        // Constructor que creara un medidor con los valores iniciales de las presiones
        public MedidorSensores(int nivelAceite, int nivelAgua, int nivelPresionNeumaticos)
        {
            this.suscriptores = new ArrayList();
            this.nivelAceite = nivelAceite;
            this.nivelAgua = nivelAgua;
            this.nivelPresionNeumaticos = nivelPresionNeumaticos;
        }

        // Comprobamos si el observer se encuentra en la lista. En caso contrario,
        // lo incluye en la lista
        public void RegistrarObserver(IObserver o)
        {
            if (!suscriptores.Contains(o))
                suscriptores.Add(o);
        }

        // Comprobamos si el observer se encuentra en la lista. En caso afirmativo,
        // lo elimina de la lista
        public void EliminarObserver(IObserver o)
        {
            if (suscriptores.Contains(o))
                suscriptores.Remove(o);
        }

        // Recorre la lista de observers e invoca su metodo Update()
        public void NotificarObservers()
        {
            // Creamos un array con el estado del Subject
            int[] valores = { this.nivelAceite, this.nivelAgua, this.nivelPresionNeumaticos };

            // Recorremos todos los objetos suscritos (observers)
            IObserver observer;
            foreach(Object o in suscriptores)
            {
                // Invocamos el metodo Update de cada observer, pasandole el array con el estado
                // del subject como parametro.
                // Cada observer ya hara lo que estime necesario con esa informacion.
                observer = (IObserver)o;
                observer.update(valores);
            }
        }

        #endregion
    }

El último paso será la creación de las clases que implementen la interfaz IObserver. Crearemos dos clases: una de ellas simbolizará el display del vehículo, es decir, la pantalla de cristal líquido que muestra la información al conductor, además de la velocidad, revoluciones, llenado del depósito del combustible… Este Observer mostrará siempre los cambios producidos en los niveles, ya que su misión será la de informar al usuario en todo momento de los niveles actuales. Es el tipo más simple de Observer, ya que se limita a presentar la información recibida del Subject.

ObserverDisplay.cs

    public class ObserverDisplay : IObserver
    {
        #region Atributos

        // Atributos que modelan el estado
        private int nivelAceite;
        private int nivelAgua;
        private int nivelPresionNeumaticos;

        // Subject al que se encuentra suscrito el observer
        private ISubject subject;

        #endregion

        #region Constructores

        // El constructor suscribira el observer al subject
        public ObserverDisplay(ISubject subject)
        {
            this.subject = subject;
            subject.RegistrarObserver(this);
        }

        #endregion

        #region Metodos de IObserver

        public void update(object o)
        {
            // Comprobamos el tipo del objeto recibido como parametro
            int[] arrayInt = null;
            if (o.GetType().Equals(typeof(int[])))
                arrayInt = (int[])o;

            // Si es del tipo esperado (int[]) y del tamano esperado (3), actualizamos los
            // atributos
            if ((arrayInt != null) && (arrayInt.Length == 3))
            {
                nivelAceite = arrayInt[0];
                nivelAgua = arrayInt[1];
                nivelPresionNeumaticos = arrayInt[2];

                // Mostramos por pantalla los valores actuales
                MostrarValores();
            }
        }

        #endregion

        // Metodo que muestra los valores en el display
        private void MostrarValores()
        {
            Console.WriteLine("Nivel de Aceite: " + nivelAceite);
            Console.WriteLine("Nivel de Agua: " + nivelAgua);
            Console.WriteLine("Presion de Neumaticos: " + nivelPresionNeumaticos + "\n");
        }
    }

Como segundo Observer codificaremos una clase ObserverAlerta que, en lugar de informar siempre de los niveles actuales, sea capaz de enviar una alerta (sonora, remota, visual o de cualquier otro tipo) en caso de que los niveles superen ciertos umbrales superiores o inferiores. En caso contrario, no realizarán ninguna acción. Esto servirá para mostrar que un Observer realizará cualquier tipo de operación con estos datos, y también la suscripción de más de uno de estos elementos.

ObserverAlerta.cs

    public class ObserverAlerta : IObserver
    {
        #region Constantes

        // Niveles minimos y maximos
        private static readonly int MIN_ACEITE = 12;
        private static readonly int MAX_ACEITE = 45;

        private static readonly int MIN_AGUA = 300;
        private static readonly int MAX_AGUA = 550;

        private static readonly int MIN_PRESION = 120;
        private static readonly int MAX_PRESION = 350;

        #endregion

        #region Atributos

        // Atributos que modelan el estado
        private int nivelAceite;
        private int nivelAgua;
        private int nivelPresionNeumaticos;

        // Subject al que se encuentra suscrito el observer
        private ISubject subject;

        #endregion

        #region Constructores

        // El constructor suscribira el observer al subject
        public ObserverAlerta(ISubject subject)
        {
            this.subject = subject;
            subject.RegistrarObserver(this);
        }

        #endregion

        #region Metodos de IObserver

        public void update(object o)
        {
            // Comprobamos el tipo del objeto recibido como parametro
            int[] arrayInt = null;
            if (o.GetType().Equals(typeof(int[])))
                arrayInt = (int[])o;

            // Si es del tipo esperado (int[]) y del tamano esperado (3), actualizamos los
            // atributos
            if ((arrayInt != null) && (arrayInt.Length == 3))
            {
                nivelAceite = arrayInt[0];
                nivelAgua = arrayInt[1];
                nivelPresionNeumaticos = arrayInt[2];

                // Comprobamos que los valores no exceden los limites
                ComprobarAceite();
                ComprobarAgua();
                ComprobarNeumaticos();
            }

        }

        #endregion

        // Metodo que comprueba los niveles de aceite
        private void ComprobarAceite()
        {
            if (nivelAceite < MIN_ACEITE)
            {
                EnviarAlerta();
                Console.WriteLine(String.Format("NIVEL DE ACEITE DEMASIADO BAJO: {0}/{1}", nivelAceite, MIN_ACEITE));
            }
            if (nivelAceite > MAX_ACEITE)
            {
                EnviarAlerta();
                Console.WriteLine(String.Format("NIVEL DE ACEITE DEMASIADO ALTO: {0}/{1}", nivelAceite, MAX_ACEITE));
            }
        }

        // Metodo que comprueba los niveles de agua
        private void ComprobarAgua()
        {
            if (nivelAgua < MIN_AGUA)
            {
                EnviarAlerta();
                Console.WriteLine(String.Format("NIVEL DE AGUA DEMASIADO BAJO: {0}/{1}", nivelAgua, MIN_AGUA));
            }
            if (nivelAgua > MAX_AGUA)
            {
                EnviarAlerta();
                Console.WriteLine(String.Format("NIVEL DE AGUA DEMASIADO ALTO: {0}/{1}", nivelAgua, MAX_AGUA));
            }
        }

        // Metodo que comprueba la presion de los neumaticos
        private void ComprobarNeumaticos()
        {
            if (nivelPresionNeumaticos < MIN_PRESION)
            {
                EnviarAlerta();
                Console.WriteLine(String.Format("NIVEL DE PRESION DE NEUMATICOS DEMASIADO BAJO: {0}/{1}", nivelPresionNeumaticos, MIN_PRESION));
            }
            if (nivelPresionNeumaticos > MAX_PRESION)
            {
                EnviarAlerta();
                Console.WriteLine(String.Format("NIVEL DE PRESION DE NEUMATICOS DEMASIADO ALTO: {0}/{1}", nivelPresionNeumaticos, MAX_PRESION));
            }
        }

        // Metodo que envie la alerta
        private void EnviarAlerta()
        {
            // Este metodo podria enviar una alerta a la centralita del vehiculo que, por ejemplo,
            // forzaria a su detencion
            Console.WriteLine("ALERTA!!");
        }
    }

Finalmente, escribiremos el código necesario para mostrar el funcionamiento del patrón. Comenzaremos instanciando un Subject con unos niveles iniciales, para a continuación instanciar dos Observers (uno de display y otro de alerta) que recibirán como parámetro el Subject al cual se suscribirán de forma automática. A continuación alteraremos los valores del medidor de sensores y comprobaremos cómo los Observers son informados y actúan en consecuencia, mostrando siempre los cambios en los valores en el caso del display y mostrando únicamente las alertas cuando los valores se encuentran fuera de los límites para el caso del observer ObserverAlerta.

            // Creamos un medidor de sensores
            ISubject sensores = new MedidorSensores(20, 380, 200);

            // Creamos dos observers: un display y un emisor de alertas.
            // Se realiza la suscripcion a traves del constructor
            IObserver display = new ObserverDisplay(sensores);
            IObserver alerta = new ObserverAlerta(sensores);

            // Modificamos valores del subject. Los observers son automaticamente informados
            // y actuaran automaticamente
            ((MedidorSensores)sensores).NivelAceite += 10;
            ((MedidorSensores)sensores).NivelAceite += 10;
            ((MedidorSensores)sensores).NivelAgua += 100;
            ((MedidorSensores)sensores).NivelPresionNeumaticos -= 50;
            ((MedidorSensores)sensores).NivelAceite += 10;
            ((MedidorSensores)sensores).NivelAgua += 100;
            ((MedidorSensores)sensores).NivelAgua += 100;

Como vemos, siempre que se produce un cambio de estado, el display recibe la notificación y actúa en consecuencia. Cuando esta notificación llega a la alerta y los valores se encuentran fuera de los límites aceptables, además se emitirá una alerta.

Como alternativa, podemos probar a eliminar la suscripción a las alertas antes de que éstas rebasen los límites:

            // Modificamos valores del subject. Los observers son automaticamente informados
            // y actuaran automaticamente
            ((MedidorSensores)sensores).NivelAceite += 10;
            ((MedidorSensores)sensores).NivelAceite += 10;
            ((MedidorSensores)sensores).NivelAgua += 100;
            ((MedidorSensores)sensores).NivelPresionNeumaticos -= 50;

            // Eliminamos el registro de las alertas y aumentamos los niveles para comprobar que no
            // son informados
            sensores.EliminarObserver(alerta);
            ((MedidorSensores)sensores).NivelAceite += 10;
            ((MedidorSensores)sensores).NivelAgua += 100;
            ((MedidorSensores)sensores).NivelAgua += 100;

En este caso, únicamente el display realizará su trabajo, ya que hemos decidido eliminar la suscripción de ObserverAlerta a lo largo del programa, lo que implicará que este objeto no reciba a partir de ese momento las notificaciones del Subject.

IObservable e IObserver

En la práctica no será necesario definir la interfaz IObservable, ya que .NET ofrece por defecto las interfaces IObserver<T> e IObservable<T> (tal y como hacía con IEnumerable<T> con el patrón iterator) para facilitarnos un poco la vida. El parámetro <T> será la clase cuyo estado quiera observarse, y en este caso no tiene por qué implementar la interfaz ISubject, sino que será parametrizada en IObservable<T> y en IObserver<T>, es decir:

• Se deberá crear una clase, por ejemplo MedidorSensores, que exponga una serie de Properties que se pretende monitorizar.
• Se codificará una clase Suscriber<MedidorSensores> que implemente la interfaz IObservable<T> (siendo T en este caso MedidorSensores) que será la encargada de gestionar las suscripciones y enviar la información a los Observers. Su formato será el siguiente:

    public class Suscriber : IObservable<MedidorSensores>
    {
        public IDisposable Subscribe(IObserver<MedidorSensores> observer)
        {
            throw new NotImplementedException();
        }
    }

• Se codificará una clase Provider<MedidorSensores> que implemente la interfaz IObserver<T> (siendo T en este caso MedidorSensores) que será la clase Observer e implementará los métodos OnCompleted, OnError y OnNext (siendo este último método el encargado de realizar las notificaciones).

    public class Provider : IObserver<MedidorSensores>
    {

        public void OnCompleted()
        {
            throw new NotImplementedException();
        }

        public void OnError(Exception error)
        {
            throw new NotImplementedException();
        }

        public void OnNext(MedidorSensores value)
        {
            throw new NotImplementedException();
        }
    }

Al final del artículo se indica un enlace en el que se podrá comprobar cómo utilizar estas interfaces aplicándolas a los datos de una estación meteorológica.

¿Cuándo utilizar este patrón? Ejemplos reales

Este patrón es útil en multitud de supuestos, pero el principal será cuando la modificación del estado de un objeto deba provocar cambio en otros objetos sin que sea necesario conocer nada acerca de la cantidad ni el tipo de dichos objetos.

Este patrón es la base de los eventos de la mayor parte de las interfaces de usuario: los Event Handlers se corresponderían con los Observers que esperan la notificación de un cambio de estado. Así, en un botón, definir un método para el evento OnClick hará que el control Button cambie su estado (por ejemplo, de no pulsado a pulsado), notificando a todos aquellos objetos que estén suscritos a él. De este modo, el Event Handler será notificado de este cambio de estado y ejecutará el código que haya sido programado para responder a dicho cambio de estado (por ejemplo, mostrar un mensaje cuando se pulsa un botón, o lo que es lo mismo, cuando el botón pasa de no pulsado a pulsado.

El patrón Observer también es la base del enlace de datos (data binding), por ejemplo en un control Gridview, que al obtener los datos de una fila de datos se encargará de dibujar la plantilla previamente configurada para mostrarle los datos al usuario.

Más adelante volveremos a este patrón, ya que es la base de uno de los patrones compuestos más utilizados hoy en día: el patrón MVC o Modelo Vista Controlador. El papel del patrón Observer en este patrón compuesto (el patrón MVC no es un patrón en sí, sino que es un patrón compuesto de varios patrones, al igual que una clase es una estructura de datos formada por otras estructuras de datos) será actuar de núcleo del mismo implementándose en el modelo. De este modo, los objetos interesados se mantienen actualizados cuando se produce un cambio de estado, haciendo que tanto la vista como el controlador estén débilmente acoplados con el modelo. Como adelanto, MVC hace uso de otros dos patrones ya vistos anteriormente: Composite (vista) y Strategy (controlador).

Fuentes:

• Head First Design Patterns (Freeman et al.)
• Observer Pattern with C# 4.0 (Rafeeq Mohamed)
• The Observer Pattern in .NET (Eric Vogel)
• Design patterns and practices in .NET: the Observer pattern (Andras Nemes)

«Permitir que un objeto modifique su comportamiento cuando su estado interno cambie. Parecerá que el objeto cambia de clase».

DesignPatterns: Elements of Reusable Object-Oriented Software

El patrón State tiene la misión fundamental de encapsular el comportamiento de un objeto dependiendo del estado en el que éste se encuentre. ¿A qué nos referimos con estado? Estrictamente hablando, podemos definir el estado de un objeto como el conjunto actual de los valores de los atributos de un objeto. Desde un punto de vista más coloquial, y refiriéndonos al patrón que estamos presentando, podríamos definir un estado como un conjunto de características que harán que el objeto tenga unas características concretas. O hablando en plata: desde el punto de vista de la orientación a objetos, podemos decir que el estado de un vehículo es de velocidad instantánea igual a cero, sin consumo de combustible, a una distancia de entre cero y veinte centímetros de la acera y con el habitáculo vacío. Desde un punto de vista coloquial (que ahora mismo es el que nos interesa), podemos decir que la suma de esos atributos nos informa de que el vehículo se encuentra en estado aparcado.

Supongo que todos conocemos el concepto de «máquina de estados«. Si no es así, lo podemos resumir con aquella máxima de «una imagen vale más que mil palabras»:

Como podemos observar, contamos con una serie de círculos que representan los estados (Apagado, Parado, En Marcha). Cada uno de esos estados se caracteriza por los valores de una serie de atributos (por ejemplo, para que el vehículo se encuentre En Marcha, se debe dar el caso de que el vehículo esté arrancado y con una velocidad distinta de cero). ¿Cómo se producen los cambios de estado? A través de las llamadas transiciones. Estas transiciones podrían compararse con nuestros métodos y funciones, que actúan sobre los valores del objeto haciendo que éste cambie de estado. O no.

Por tanto, tenemos un conjunto limitado de estados (Apagado, Parado, En Marcha) y otro de transiciones (Contacto, Acelerar, Frenar). El factor determinante se encuentra en que dependiendo en qué estado nos encontremos, las transiciones actuarán de forma distinta, realizando ciertas operaciones, transiciones a otros estados… o no realizando absolutamente nada. Como ejemplo, pisar el acelerador con el vehículo apagado no realizará ningún cambio, mientras que si pisamos el acelerador con el vehículo arrancado, el coche se pondrá en movimiento, ganando velocidad (y realizando una transición del estado PARADO al estado EN_MARCHA).

Pongámosle código a nuestro ejemplo:

Un pequeño conjunto de estados

Modelaremos este ejemplo con una clase a la que llamaremos «VehiculoBasico». Su funcionamiento será sencillo: contará con una variable entera que almacenará el estado actual, otra que almacenará la velocidad, y un conjunto de métodos que serán los encargados de realizar las transiciones. ¿Cómo lo controlamos? Pues a priori, no tenemos mucho donde elegir: a través de una serie de sentencias switch o if…else, que comprueben el estado actual y actúen de forma distinta dependiendo del estado en el que nos encontremos. Comencemos con la declaración de la clase, un conjunto de enteros que modelen los posibles estados y sus atributos:

    public class VehiculoBasico
    {
        // Estados
        private const int APAGADO = 0;
        private const int PARADO = 1;
        private const int EN_MARCHA = 2;

        // Atributos
        private const int VELOCIDAD_MAXIMA = 200;
        private int estado = APAGADO;
        private int velocidadActual = 0;

    }

A continuación modelaremos cada uno de los métodos que pueden realizar transiciones. Comenzaremos con el método Contacto:

        public void Contacto()
        {
            switch (estado)
            {
                case APAGADO:
                    {
                        // El vehiculo arranca
                        estado = PARADO;
                        velocidadActual = 0;
                        Console.WriteLine("El vehiculo se encuentra ahora PARADO");
                        break;
                    }
                case PARADO:
                    {
                        // El vehiculo se apaga
                        estado = APAGADO;
                        Console.WriteLine("El vehiculo se encuentra ahora APAGADO");
                        break;
                    }
                case EN_MARCHA:
                    {
                        // No se puede detener el vehiculo en marcha!
                        Console.WriteLine("ERROR: No se puede cortar el contacto en marcha!");
                        break;
                    }
                default:
                    break;
            }
        } 

Como vemos, lo primero que haremos en el método será comprobar el estado actual y/o otros atributos. Acorde a esta información, realizaremos las operaciones oportunas. Seguiremos con el método Acelerar

        public void Acelerar()
        {
            switch (estado)
            {
                case APAGADO:
                    {
                        // Acelerar con el vehiculo apagado no sirve de mucho 
                        Console.WriteLine("ERROR: El vehiculo esta apagado. Efectue el contacto para iniciar");
                        break;
                    }
                case PARADO:
                    {
                        // El vehiculo se pone en marcha. Aumenta la velocidad y cambiamos de estado
                        velocidadActual += 10;
                        estado = EN_MARCHA;
                        Console.WriteLine("El vehiculo se encuentra ahora EN_MARCHA");
                        Console.WriteLine("Velocidad actual: " + velocidadActual);
                        break;
                    }
                case EN_MARCHA:
                    {
                        // Aumentamos la velocidad, permaneciendo en el mismo estado
                        if (velocidadActual >= VELOCIDAD_MAXIMA)
                            Console.WriteLine("ERROR: El coche ha alcanzado su velocidad maxima");
                        else
                            velocidadActual += 10;
                        break;
                    }
                default:
                    break;
            }
        }

Finalmente, codificaremos el último de los métodos: Frenar.

        public void Frenar()
        {
            switch (estado)
            {
                case APAGADO:
                    {
                        // Frenar con el vehiculo parado tampoco sirve de mucho...
                        Console.WriteLine("ERROR: El vehiculo esta apagado. Efectue el contacto para iniciar");
                        break;
                    }
                case PARADO:
                    {
                        // No ocurre nada. Si el vehiculo ya se encuentra detenido, no habra efecto alguno
                        Console.WriteLine("ERROR: El vehiculo ya se encuentra detenido");
                        break;
                    }
                case EN_MARCHA:
                    {
                        // Reducimos la velocidad. Si esta llega a 0, cambiaremos a estado "PARADO"
                        velocidadActual -= 10;
                        if (velocidadActual <= 0)
                        {
                            estado = PARADO;
                            Console.WriteLine("El vehiculo se encuentra ahora PARADO");
                        }
                        Console.WriteLine("Velocidad actual: " + velocidadActual);
                        break;
                    }
                default:
                    break;
            }
        }

Ahora codificaremos un pequeño programita que haga uso de nuestra clase:

            VehiculoBasico vb = new VehiculoBasico();

            vb.Acelerar();
            vb.Contacto();
            vb.Acelerar();
            vb.Acelerar();
            vb.Acelerar();
            vb.Frenar();
            vb.Frenar();
            vb.Frenar();
            vb.Frenar();

El resultado es bastante previsible: al acelerar sin arrancar obtenemos un error. Damos contacto, aceleramos un poco y vamos frenando hasta que el vehículo se detiene. E incluso pisamos el freno estando ya parados, por lo que el vehículo nos informa de ello.

Encapsulando el estado

Todo esto resulta muy sencillo, pero ¿qué ocurriría si, por ejemplo, los requisitos de nuestro programa nos exigieran añadir un nuevo estado? Como podemos imaginar, cada uno de los métodos tendrá que añadir una nueva línea a su switch para contemplar esta posibilidad, amén de que seguramente tengamos que modificar el código ya existente para «encajar» nuestro nuevo estado dentro de la funcionalidad del programa. Por ejemplo, si imaginamos un estado «Sin Gasolina» que indique que nos hemos quedado sin combustible, implicaría:

• Añadir una nueva constante SIN_COMBUSTIBLE para modelar el estado.
• Añadir un nuevo case que contemple este estado en cada uno de los métodos existentes (Acelerar, Frenar y Contacto)
• Modificar los métodos para contemplar que el vehículo no arrancará sin combustible, y que no podrá aumentar su velocidad si nos encontramos en marcha.

¿Cómo evitar este quebradero de cabeza? Siguiendo el principio de encapsular lo que cambia que tan buenos resultados nos ha dado hasta el momento. Y como lo que cambia parecen ser los estados, ¡vamos a encapsularlos!

Lo primero que deberemos hacer será crear una interfaz común que todos los estados deberán implementar. Esta interfaz, por lo tanto, deberá exponer los métodos Acelerar, Frenar y Contacto.

    public interface State
    {
        void Acelerar();
        void Frenar();
        void Contacto();
    }

Lo siguiente que haremos será crear una clase que se denominará clase de contexto, encargada de albergar el estado actual junto al resto de los atributos que se consideren oportunos. En nuestro caso concreto, será el vehículo:

Vehiculo.cs:

    public class Vehiculo
    {
        #region Atributos

        private State estado;                 // Estado actual del vehiculo (apagado, parado, en marcha, sin combustible)
        private int velocidadActual = 0;      // Velocidad actual del vehiculo
        private int combustibleActual = 0;    // Cantidad de combustible restante

        #endregion

        #region Properties

        // Asigna o recupera el estado del vehiculo
        public State Estado
        {
            get { return estado; }
            set { estado = value; }
        }

        // Asigna o recupera la velocidad actual del vehiculo
        public int VelocidadActual
        {
            get { return velocidadActual; }
            set { velocidadActual = value; }
        }

        // Obtiene la cantidad de combustible actual
        public int CombustibleActual
        {
            get { return combustibleActual; }
        }

        #endregion

        #region Constructores

        // El constructor inserta el combustible del que dispondra el vehiculo
        public Vehiculo(int combustible)
        {
            this.combustibleActual = combustible;
            //TODO:
            //Indicar un estado inicial (Apagado)
        }

        #endregion

        #region Metodos relacionados con los estados

        // Los metodos del contexto invocaran el metodo de la interfaz State, delegando las operaciones
        // dependientes del estado en las clases que los implementen.
        public void Acelerar()
        {
            estado.Acelerar();
            Console.WriteLine("Velocidad actual: " + velocidadActual + ". Combustible restante: " + combustibleActual);
        }

        public void Frenar()
        {
            estado.Frenar();
        }

        public void Contacto()
        {
            estado.Contacto();
        }

        #endregion

        #region Otros metodos

        public void ModificarVelocidad(int kmh)
        {
            velocidadActual += kmh;
        }

        public void ModificarCombustible(int decilitros)
        {
            combustibleActual += decilitros;
        }

        #endregion
    }

Volveremos a esta clase dentro de un momento. Antes deberemos implementar la interfaz con una clase por cada estado existente en el sistema. Nuestra idea será crear una clase por cada uno de los estados, que implemente los métodos de la interfaz State. Además, añadiremos un nuevo estado Sin Combustible, que será un estado final (una vez alcanzado, no podrá cambiarse de estado).

La idea de este nuevo modelo es modificar el diagrama anterior para contemplar el estado SinCombustible, de forma similar a la siguiente:

Comencemos por el primero de ellos: ApagadoState.

    public class ApagadoState : State
    {
        // Referencia a la clase de contexto
        private Vehiculo v;

        // Constructor que inyecta la dependencia en la clase actual
        public ApagadoState(Vehiculo v)
        {
            this.v = v;
        }

        public void Acelerar()
        { }

        public void Frenar()
        { }

        public void Contacto()
        { }
    }

Crearemos otras tres clases similares que implementen State: ParadoState, EnMarchaState y SinCombustibleState. Las cuatro clases que implementan los estados tienen como característica común (además de los métodos de la interfaz) que su constructor recibe como parámetro una referencia al contexto, de modo que puedan utilizar sus métodos públicos y, sobre todo, para que puedan realizar la transición de estados inyectando ese objeto en los nuevos objetos que se creen.

Por lo tanto, una vez comprendido esto, procederemos a codificar la funcionalidad de los estados, incluyendo las transiciones:

ApagadoState.cs:

    public class ApagadoState : State
    {
        // Referencia a la clase de contexto
        private Vehiculo v;

        // Constructor que inyecta la dependencia en la clase actual
        public ApagadoState(Vehiculo v)
        {
            this.v = v;
        }

        public void Acelerar()
        {
            // Acelerar con el vehiculo apagado no sirve de mucho 
            Console.WriteLine("ERROR: El vehiculo esta apagado. Efectue el contacto para iniciar");
        }

        public void Frenar()
        {
            // Frenar con el vehiculo parado tampoco sirve de mucho...
            Console.WriteLine("ERROR: El vehiculo esta apagado. Efectue el contacto para iniciar");
        }

        public void Contacto()
        {
            // Comprobamos que el vehiculo disponga de combustible
            if (v.CombustibleActual > 0)
            {
                // El vehiculo arranca -> Cambio de estado
                //estado = PARADO;
                v.Estado = new ParadoState(v);
                Console.WriteLine("El vehiculo se encuentra ahora PARADO");
                v.VelocidadActual = 0;
            }
            else
            {
                // El vehiculo no arranca -> Sin combustible
                //estado = SIN COMBUSTIBLE
                v.Estado = new SinCombustibleState(v);
                Console.WriteLine("El vehiculo se encuentra sin combustible");
            }
        }
    }

Como observamos, cada método es independiente e implementa su propia funcionalidad, incluyendo la transición de estados. Para ello realiza un new pasando como parámetro al constructor la referencia al contexto (el objeto de la clase Vehiculo). El resto de estados seguirán un patrón similar:

ParadoState.cs:

    public class ParadoState :State
    {
        // Referencia a la clase de contexto
        private Vehiculo v;

        // Constructor que inyecta la dependencia en la clase actual
        public ParadoState(Vehiculo v)
        {
            this.v = v;
        }

        public void Acelerar()
        {
            // Comprobamos que el vehiculo disponga de combustible
            if (v.CombustibleActual > 0)
            {
                // El vehiculo se pone en marcha. Aumenta la velocidad y cambiamos de estado
                //estado = EN_MARCHA;
                v.Estado = new EnMarchaState(v);
                Console.WriteLine("El vehiculo se encuentra ahora EN MARCHA");
                v.ModificarVelocidad(10);
                v.ModificarCombustible(-10);
            }
            else
            {
                //estado = SIN COMBUSTIBLE
                v.Estado = new SinCombustibleState(v);
                Console.WriteLine("El vehiculo se encuentra ahora SIN COMBUSTIBLE");
            }
        }

        public void Frenar()
        {
            // No ocurre nada. Si el vehiculo ya se encuentra detenido, no habra efecto alguno
            Console.WriteLine("ERROR: El vehiculo ya se encuentra detenido");
        }

        public void Contacto()
        {
            // El vehiculo se apaga
            // estado = APAGADO;
            v.Estado = new ApagadoState(v);
            Console.WriteLine("El vehiculo se encuentra ahora APAGADO");
        }
    }

EnMarchaState.cs:

    public class EnMarchaState : State
    {
        private const int VELOCIDAD_MAXIMA = 200;

        // Referencia a la clase de contexto
        private Vehiculo v;

        // Constructor que inyecta la dependencia en la clase actual
        public EnMarchaState(Vehiculo v)
        {
            this.v = v;
        }

        public void Acelerar()
        {
            if (v.CombustibleActual > 0)
            {
                // Aumentamos la velocidad, permaneciendo en el mismo estado
                if (v.VelocidadActual >= VELOCIDAD_MAXIMA)
                {
                    Console.WriteLine("ERROR: El coche ha alcanzado su velocidad maxima");
                    v.ModificarCombustible(-10);
                }
                else
                {
                    v.ModificarVelocidad(10);
                    v.ModificarCombustible(-10);
                }
            }
            else
            {
                //estado = SIN COMBUSTIBLE
                v.Estado = new SinCombustibleState(v);
                Console.WriteLine("El vehiculo se ha quedado sin combustible");
            }
        }

        public void Frenar()
        {
            // Reducimos la velocidad. Si esta llega a 0, cambiaremos a estado "PARADO"
            v.ModificarVelocidad(-10);
            if (v.VelocidadActual <= 0)
            {
                //estado = PARADO;
                v.Estado = new ParadoState(v);
                Console.WriteLine("El vehiculo se encuentra ahora PARADO");
            }
        }

        public void Contacto()
        {
            // No se puede detener el vehiculo en marcha!
            Console.WriteLine("ERROR: No se puede cortar el contacto en marcha!");
        }
    }
<

SinCombustibleState.cs:

    public class SinCombustibleState : State
    {
        // Referencia a la clase de contexto
        private Vehiculo v;

        // Constructor que inyecta la dependencia en la clase actual
        public SinCombustibleState(Vehiculo v)
        {
            this.v = v;
        }

        public void Acelerar()
        {
            Console.WriteLine("ERROR: El vehiculo se encuentra sin combustible");
        }

        public void Frenar()
        {
            Console.WriteLine("ERROR: El vehiculo se encuentra sin combustible");
        }

        public void Contacto()
        {
            Console.WriteLine("ERROR: El vehiculo se encuentra sin combustible");
        }
    }

Ahora modificaremos el constructor del contexto para que disponga de un estado inicial (por ejemplo, ApagadoState)

        // El constructor inserta el combustible del que dispondra el vehiculo e instancia el
        // estado inicial (apagado)
        public Vehiculo(int combustible)
        {
            this.combustibleActual = combustible;

            //Indicar un estado inicial (Apagado)
            estado = new ApagadoState(this);
        }

Finalmente, disponemos de un pequeño fragmento de código que haga uso de nuestro patrón:

            Vehiculo v = new Vehiculo(20);

            v.Acelerar();
            v.Contacto();
            v.Acelerar();
            v.Acelerar();
            v.Acelerar();
            v.Frenar();
            v.Frenar();
            v.Frenar();
            v.Frenar();

El resultado de nuestra ejecución será el siguiente:

¿Cuándo utilizar este patrón? Ejemplos reales

Se suele decir que los patrones Strategy y State son hermanos que fueron separados al nacer. Esto se debe a que sus razones de ser son muy parecidas: modificar el funcionamiento de un objeto en tiempo de ejecución de forma transparente a través de un proceso de composición. La diferencia fundamental, sin embargo, se encuentra en que el patrón Strategy tiene como objetivo proporcionar alternativas para realizar una misma tarea, aunque ésta sea de alto nivel, es decir: el patrón Strategy es adecuado cuando queremos, por ejemplo, serializar un objeto. Cada una de las implementaciones encapsulará una forma distinta de serialización: binaria, Base64, como un fichero XML, JSON, etc. State, por su parte, tiene su razón de ser en proporcionar comportamientos distintos cuando la aplicación se encuentra en estados distintos. Con este patrón, la clase que implemente nuestro State realizará operaciones distintas dependiendo de su estado, no proporcionará «varias formas de hacer lo mismo». Por ello, Strategy y State son patrones distintos, aunque muy similares: Strategy encapsula el algoritmo, mientras que State encapsulará un comportamiento que variará dependiendo del estado en el que se encuentre el programa.

Por lo tanto, la aplicación de este patrón será adecuada en entornos en los que se identifiquen «estados» con operaciones comunes que varíen su comportamiento dependiendo de en cuál de ellos se encuentren activos. Un buen ejemplo de este comportamiento sería la implementación de un Workflow de un gestor de defectos en el que un elemento de trabajo pueda encontrarse en distintos estados (nuevo, en curso, corregido…) y en el que cada uno de los estados implica un conjunto de posibles operaciones y transiciones que difieren entre sí.

Una posible mejora de este patrón consiste en extraer cualquier tipo de información variable (en este ejemplo, la velocidad y el combustible) y situarla en el contexto o en otra clase externa, permitiendo de este modo modelar cada estado de forma estática o a través de un patrón Singleton. Así, en lugar de instanciar un estado cada vez que se necesite realizar un cambio, bastará con referenciar la instancia ya existente, que únicamente incluirá el comportamiento (el código mostrado en este artículo sería un buen ejemplo en el que podría aplicarse esta alternativa).

Fuentes:

• Head First Design Patterns (Freeman et al.)
• Design Pattern Uncovered: State Pattern (James Sugrue)
• .NET State Pattern (doFactory)
• The State and Strategy Patterns (Bob Tarr, pdf)

]]> https://danielggarcia.wordpress.com/2014/05/20/patrones-de-comportamiento-v-patron-state/feed/ 8 1102 danielggarcia State Pattern Class Diagram Resultado https://danielggarcia.wordpress.com/2014/05/12/patrones-de-comportamiento-iv-patron-strategy/ https://danielggarcia.wordpress.com/2014/05/12/patrones-de-comportamiento-iv-patron-strategy/#comments Mon, 12 May 2014 21:26:53 +0000 http://danielggarcia.wordpress.com/?p=1091 Objetivo:

«Definir una familia de algoritmos, encapsular cada uno de ellos y hacerlos intercambiables. Strategy permite cambiar el algoritmo independientemente de los clientes que lo utilicen».

Design Patterns: Elements of Reusable Object-Oriented Software

En el artículo anterior veíamos cómo un patrón de diseño puede ayudarnos a encapsular distintos algoritmos a partir de una «plantilla» cuyos hijos se encargaban de especializar. El patrón Strategy, por su parte, no bucea en los detalles, sino que va un paso más allá: encapsulará un algoritmo completo ignorando los detalles de su implementación, permitiendo intercambiarlo en tiempo de ejecución para permitir actuar a la clase cliente con un comportamiento distinto.

El nombre de este patrón evoca la posibilidad de realizar un cambio de estrategia en tiempo de ejecución sustituyendo un objeto que se encargará de implementarla. No nos preocupará el «cómo». De hecho, ni siquiera nos importará «el qué»: la clase que actúa como interfaz del patrón únicamente tendrá que exponer el método o métodos que deberá invocar el cliente.

Strategy pattern y videojuegos

Un ejemplo clásico para entender este patrón es el de un protagonista de un videojuego en el cual manejamos a un soldado que puede portar y utilizar varias armas distintas. La clase (o clases) que representan a nuestro soldado no deberían de preocuparse de los detalles de las armas que porta: debería bastar, por ejemplo, con un método de interfaz «atacar» que dispare el arma actual y otro método «recargar» que inserte munición en ésta (si se diera el caso). En un momento dado, otro método «cambiarArma» podrá sustituir el objeto equipado por otro, manteniendo la interfaz intacta. Da igual que nuestro soldado porte un rifle, una pistola o un fusil: los detalles de cada estrategia estarán encapsulados dentro de cada una de las clases intercambiables que representan las armas. Nuestra clase cliente (el soldado) únicamente debe preocuparse de las acciones comunes a todas ellas: atacar, recargar y cambiar de arma. Éste último método, de hecho, será el encargado de realizar la operación de «cambio de estrategia» que forma parte del patrón.

Por lo tanto, el patrón Strategy es, como podemos imaginar, uno de los patrones más utilizados a la hora de diseñar software. Siempre que exista una posibilidad de realizar una tarea de distintas formas posibles, el patrón Strategy tendrá algo que decir al respecto.

Nuestro diagrama de clases muestra una interfaz denominada IStrategy que expone un método operacion(). Las clases que implementen esta interfaz serán aquellas que implementen las distintas estrategias a realizar por el cliente, y como podemos observar, no tienen mayor dificultad: una interfaz, varias clases que la implementan. Programación Orientada a Objetos básica.

La filosofía del patrón, por lo tanto, radica en el enlace entre la llamada clase de contexto y la propia interfaz. Esta clase de contexto será el «broker» o intermediario entre el cliente y las clases que implementan la estrategia, y por lo tanto, sus funciones serán simples: cambiar la estrategia actual y ejecutarla. Si hablásemos de un videojuego, el contexto sería el objeto encargado de equipar la pistola al pulsar la tecla «1» y de invocar la funcionalidad de disparo cuando hacemos click con el ratón. Esto se traduciría por instanciar un objeto StrategyPistola en la referencia IStrategy e invocar el método «atacar()» de ésta para que la clase que implementa la interfaz se encargue del trabajo sucio (¡nunca mejor dicho!).

Implementando el patrón

Pese a que el ejemplo de nuestro videojuego es bastante ilustrativo, dado que en esta serie de artículos tenemos fijación por los coches, implementaremos el patrón a través de un hipotético módulo de la centralita del vehículo que nos permitirá alternar entre una conducción normal y deportiva. La diferencia entre ambas será simple: mayor consumo, mayor potencia y mayor velocidad. Podríamos añadir más comportamientos «personalizados», como el endurecimiento de la suspensión, pero con estos dos elementos será suficiente para captar la idea.

Comencemos añadiendo la interfaz ITipoConduccion, que simbolizará la interfaz de la estrategia (IStrategy). Le añadiremos tres métodos: uno para obtener la descripción del tipo de conducción actual, otro que proporcione el incremento de velocidad en relación al combustible inyectado y un tercer método que indique la cantidad de potencia suministrada por el motor, también en proporción al combustible que recibe.
ITipoConduccion.cs

ITipoConduccion.cs

    public interface ITipoConduccion
    {
        string ObtenerDescripcion();
        int ObtenerPotencia(float decilitrosCombustible);
        int ObtenerIncrementoVelocidad(float decilitrosCombustible);
    }

A continuación añadiremos las estrategias en sí, es decir, las clases que implementan la interfaz y dotan de distintos comportamientos que serán seleccionados por el contexto. Habíamos dicho que utilizaríamos dos: conducción normal y conducción deportiva. Por lo tanto, crearemos dos clases que proporcionen distintos comportamientos para los mismos métodos:

ConduccionNormal.cs

    public class ConduccionNormal : ITipoConduccion
    {
        public string ObtenerDescripcion()
        {
            return "Conduccion Normal";
        }

        public int ObtenerPotencia(float decilitrosCombustible)
        {
            return (int)(decilitrosCombustible * 0.842) + 3;
        }

        public int ObtenerIncrementoVelocidad(float decilitrosCombustible)
        {
            return (int)(decilitrosCombustible * 0.422) + 2;
        }
    }

ConduccionDeportiva.cs

    public class ConduccionDeportiva : ITipoConduccion
    {
        public string ObtenerDescripcion()
        {
            return "Conduccion Deportiva";
        }

        public int ObtenerPotencia(float decilitrosCombustible)
        {
            return (int)(decilitrosCombustible * 0.987) + 5;
        }

        public int ObtenerIncrementoVelocidad(float decilitrosCombustible)
        {
            return (int)(decilitrosCombustible * 0.618) + 3;
        }
    }

Lo siguiente será crear el contexto. Esta clase será la encargada de establecer la conexión entre el cliente y las clases que implementan la estrategia, sustituyendo la clase que la implementa dependiendo del comportamiento esperado. Por lo tanto, se compondrá de una referencia a la interfaz que implementarán las estrategias más un método que permita cambiar de instancia (es decir, una property o un setter de toda la vida). A partir de esta funcionalidad básica, el contexto podrá realizar otras operaciones relacionadas con la estrategia que pretende modelar, como por ejemplo la invocación de sus métodos o la encapsulación del cambio de estrategia.

Contexto.cs

    public class Contexto
    {
        // Referencia a la interfaz
        private ITipoConduccion tipoConduccion;

        // Propiedad que establecerá un nuevo tipo de conducción (cambio de estrategia)
        public ITipoConduccion TipoConduccion
        {
            get { return tipoConduccion; }
            set { this.tipoConduccion = value; }
        }

		// Métodos de servicio (invocan los métodos implementados por las estrategias)
        public string ObtenerDescripcion()
        {
            return tipoConduccion.ObtenerDescripcion();
        }

        public int IncrementarVelocidad(float combustible)
        {
            return tipoConduccion.ObtenerIncrementoVelocidad(combustible);
        }

        public int IncrementarPotencia(float combustible)
        {
            return tipoConduccion.ObtenerPotencia(combustible);
        }
    }

En realidad, la propia clase cliente puede actuar como clase de contexto, pero siempre será mejor minimizar el acoplamiento entre las estrategias y las reglas de negocio. De este modo, respetaremos otro de los principios de la orientación a objetos: una clase, una responsabilidad. Para comprobar el funcionamiento de nuestro cliente, bastará con utilizar el siguiente código que hará uso del contexto para cambiar de estrategia en tiempo de ejecución:

Vehiculo.cs

    public class Vehiculo
    {
        private Contexto contexto;

        public Vehiculo()
        {
            contexto = new Contexto();
        }

        public void ConduccionDeportiva()
        {
            ITipoConduccion conduccionDeportiva = new ConduccionDeportiva();
            contexto.TipoConduccion = conduccionDeportiva;
        }

        public void ConduccionNormal()
        {
            ITipoConduccion conduccionNormal = new ConduccionNormal();
            contexto.TipoConduccion = conduccionNormal;
        }

        // Métodos que invocan la funcionalidad implementada por la interfaz
        public void Acelerar(float combustible)
        {
            string descripcion = contexto.ObtenerDescripcion();
            int incrementoVelocidad = contexto.IncrementarVelocidad(combustible);
            int potencia = contexto.IncrementarPotencia(combustible);

            Console.WriteLine("Tipo de conducción " + descripcion);
            Console.WriteLine("Combustible inyectado: " + combustible);
            Console.WriteLine("Potencia proporcionada: " + potencia);
            Console.WriteLine("Incremento de velocidad: " + incrementoVelocidad);
        }
    }

Finalmente, el código que invoca a nuestro cliente, que será el siguiente:

        static void Main(string[] args)
        {
            Vehiculo v = new Vehiculo();
            v.ConduccionDeportiva();
            v.Acelerar(2.4f);

            Console.WriteLine("");

            v.ConduccionNormal();
            v.Acelerar(2.4f);

            Console.ReadLine();
        }

El resultado final será el siguiente:

¿Cuándo utilizar este patrón? Ejemplos reales

Este patrón es aconsejable, como ya hemos comentado, en situaciones en los que una misma operación (o conjunto de operaciones) puedan realizarse de formas distintas. A grosso modo, el patrón Strategy realiza una tarea bastante similar al patrón Template Method, salvo porque en este caso el algoritmo no tiene por qué contar con pasos en común y porque Strategy confía en la composición mientras que Template Method se basa en la herencia.

Ejemplos reales de este patrón se aplican, por ejemplo, la serialización de objetos. Una interfaz que exponga un método serialize() podrá codificar un objeto en distintos formatos (String64, XML, JSON). El cliente no necesita saber cómo se realizará esta operación: bastará con que el contexto seleccione la estrategia adecuada y el resultado de la operación dependerá de la opción concreta que se haya seleccionado. Del mismo modo podemos pensar en una conexión a un servicio web: podremos realizarla mediante TCP/IP, HTTP, HTTPS, Named Pipes… todo esto deberá ser transparente para el cliente: El contexto será el encargado de adoptar una forma concreta de conexión.

¿Más ejemplos? Los compresores funcionan a través de estrategias (se utiliza un algoritmo distinto para comprimir en zip o en rar), y en general, cualquier programa capaz de almacenar y transmitir datos en distintos formatos implementarán este patrón. Por lo tanto, como podemos imaginar, nos encontramos, tanto por su utilidad como por su sencillez, con uno de los patrones más utilizados de todos los expuestos por el GoF.

Fuentes:

• Head First Design Patterns (Freeman et al.)

• Object Oriented Design: Strategy

• Design Patterns with UML: Strategy

• DOFactory: Strategy Pattern

«Permitir que ciertos pasos de un algoritmo definidos en un método de una clase sean redefinidos en sus clases derivadas sin necesidad de sobrecargar la operación entera».

Design Patterns: Elements of Reusable Object-Oriented Software

Si el patrón Command nos permite encapsular una invocación a un método, el patrón Template Method o Método Modelo establece una forma de encapsular algoritmos. Este patrón se basa en un principio muy sencillo: si un algoritmo puede aplicarse a varios supuestos en los que únicamente cambie un pequeño número de operaciones, la idea será utilizar una clase para modelarlo a través de sus operaciones. Esta clase base se encargará de definir los pasos comunes del algoritmo, mientras que las clases que hereden de ella implementarán los detalles propios de cada caso concreto, es decir, el código específico para cada caso.

El procedimiento es sencillo:

• Se declara una clase abstracta, que será la plantilla o modelo. Esta clase definirá una serie de funciones y métodos. Aquellas que sean comunes estarán implementadas. Aquellas que dependan de cada caso concreto, se declararán como abstractas, obligando a las clases hijas a implementarlas.
• Cada clase derivada implementará los métodos específicos, acudiendo a la clase base para ejecutar el código común.
• La clase base también se encargará de la lógica del algoritmo, ejecutando los pasos en un orden preestablecido (las clases hijas no deberían poder modificar el algoritmo, únicamente definir la funcionalidad específica que tienen que implementar).

Dado que la clase padre es la que se encarga de llamar los métodos de las clases derivadas (los pasos del algoritmo estarán implementado en la clase base), se trata de una aplicación manifiesta del principio de inversión de dependencias: la clase base no tiene por qué saber nada acerca de sus hijas, pero aún así, se encargará de invocar su funcionalidad cuando sea necesario. El principio de Hollywood («no nos llames, nosotros te llamaremos») vuelve a entrar en escena.

Implementando el patrón

En anteriores artículos hemos hecho uso de este patrón sin ser conscientes de ello al definir el funcionamiento de un motor de cuatro tiempos. Veíamos que el funcionamiento de un motor de gasolina se basaba en el siguiente algoritmo:

• Admisión: el descenso del pistón crea un vacío que aspira la mezcla de aire y combustible de la válvula de admisión. La válvula de escape permanece cerrada.
• Compresión: una vez que el pistón ha bajado hasta el final, se cierra la válvula de admisión. El pistón asciende, comprimiendo la mezcla y aumentando la presión.
• Explosión: el pistón alcanza la parte superior y la bujía produce una chispa que hace explotar la mezcla de aire y combustible, haciendo que el pistón vuelva a descender.
• Escape: la válvula de escape se abre. El pistón asciende nuevamente, empujando los gases resultantes de la explosión y comenzando un nuevo ciclo.

Ahora veamos cómo funciona, a grandes rasgos, un motor diesel de cuatro tiempos:

• Admisión: el descenso del pistón crea un vacío que aspira aire desde la válvula de admisión. La válvula de escape permanece cerrada.
• Compresión: una vez que el pistón ha bajado hasta el final, se cierra la válvula de admisión. El pistón asciende, comprimiendo el aire y aumentando la presión.
• Combustión: los inyectores pulverizan el combustible, haciendo que la presión se encargue de aumentar la temperatura, haciendo que se produzca la combustión y la expansión de los gases que fuerzan el descenso del pistón.
• Escape: la válvula de escape se abre. El pistón asciende nuevamente, empujando los gases resultantes de la explosión y comenzando un nuevo ciclo.

Tal y como observamos, ambos motores tienen un funcionamiento muy similar. Las fases 2 y 4 (compresión y escape) son idénticas, la fase 1 (admisión) varía ligeramente, mientras que la fase 3 (explosión en el motor de gasolina, combustión en el motor diesel) tiene un comportamiento diferente. ¿Cómo encaja aquí el patrón Template Method?

Dado que el algoritmo para realizar el ciclo del motor tiene los mismos pasos efectuados en el mismo orden, es el contexto adecuado para utilizar este patrón. Podemos crear una superclase Motor que implemente las fases comunes a ambos motores (Compresión, Escape) más el algoritmo RealizarFaseMotor, que será el encargado de invocar los métodos en un orden fijo. Esta ejecución será invariable, por lo que las clases derivadas únicamente podrán (y deberán) implementar las partes específicas de cada motor.

Dado que la fase Admisión varía ligeramente (inyección de mezcla de combustible y gas en el motor de gasolina frente a inyección de gas en el motor diesel), es posible implementar la parte común en el propio método de la superclase y encapsular únicamente la parte que varía en otro método que será invocado desde Compresión. Así respetaremos otro de los principios de la orientación a objetos: encapsular aquello que es susceptible de cambiar.

Comencemos creando la clase abstracta Motor. Si bien en otros casos hemos hablado de utilizar una interfaz o una clase abstracta para implementar una abstracción, en este caso será necesario utilizar una clase abstracta, no una interfaz. ¿Por qué? Porque si utilizamos una interfaz únicamente podremos definir la firma de los métodos a utilizar, pero no podremos codificar una funcionalidad común, que es lo que pretende este patrón. Por lo tanto, Motor será una clase abstracta que implementará de forma explícita la parte común y declarará como abstractos los métodos que las clases derivadas estarán obligadas a implementar. Comenzaremos declarando unas cuantas variables: dos para modelar el estado de las válvulas y otras dos para modelar el ángulo actual del cigüeñal y del árbol de levas. También crearemos un método que «reinicie» el ángulo de estos dos elementos, manteniéndolos siempre entre 0 y 359 grados:

    public abstract class Motor
    {
        // Estado de las válvulas
        private bool valvulaAdmisionAbierta = false;
        private bool valvulaEscapeAbierta = false;

        // Ángulos del cigueñal y del árbol de levas
        protected int anguloCiguenal = 0;
        protected int anguloArbolLevas = 0;


        // Método que mantendrá el ángulo entre 0 y 359 grados
        protected int SumarAngulo(int anguloActual, int cantidad)
        {
            if (anguloActual + cantidad >= 360)
                return anguloActual + cantidad - 360;
            else
                return anguloActual + cantidad;
        }

    }

A continuación modelaremos los dos métodos que implementará de forma explícita la clase base: compresión y escape:

        // Segunda Fase: Compresión
        protected void Compresion()
        {
            Console.WriteLine("COMENZANDO FASE DE COMPRESION");

            // Se cierra la válvula de admisión
            valvulaAdmisionAbierta = false;

            // Giros del cigueñal y del árbol de levas
            anguloCiguenal = SumarAngulo(anguloCiguenal, 360);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 180);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas);

            Console.WriteLine("Valvula de admision abierta: " + valvulaAdmisionAbierta);
            Console.WriteLine("Valvula de escape abierta: " + valvulaEscapeAbierta + "\n");
        }
        // Cuarta Fase: Escape
        protected void Escape()
        {
            Console.WriteLine("COMENZANDO FASE DE ESCAPE");

            // Se abre la válvula de escape
            valvulaEscapeAbierta = true;

            // Giros del cigueñal y del árbol de levas
            anguloCiguenal = SumarAngulo(anguloCiguenal, 180);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 90);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas);

            Console.WriteLine("Gases expulsados. Fin de ciclo");
        }

    }

Hemos dicho que la tercera fase depende exclusivamente de las clases derivadas. Por lo tanto, nuestra clase motor se limitará a declarar el método como abstracto y obligar a las clases derivadas a implementar la funcionalidad específica de cada motor:

        // Tercera Fase: Consumo del combustible. Dado que depende del motor concreto,
        // este método será abstracto y deberá ser implementado por la clase derivada.
        protected abstract void ConsumirCombustible();

Nos queda la primera fase: admisión. Hemos dicho que parte de la funcionalidad es común (bajada del pistón, apertura de la válvula de admisión), pero otra parte depende de si el motor es de gasolina (inyección de combustible y aire) o diesel (inyección de aire). Por tanto, creamos otro método abstracto que las clases hija tendrán que codificar (BajarPiston()) y se invoca desde el método Admision(), que codificará la parte común:

        // La bajada del pistón depende del motor concreto, por lo que deberá ser implementada
        // por la clase hija.
        protected abstract void BajarPiston();

        // Primera Fase: Admisión
        protected void Admision()
        {
            Console.WriteLine("COMENZANDO FASE DE ADMISION");

            // Se abre la válvula de admisión y se cierra la válvula de escape
            valvulaAdmisionAbierta = true;
            valvulaEscapeAbierta = false;

            // Se baja el pistón. Esta operación será distinta en el motor diesel (que
            // inyectará aire) o gasolina (que inyectará una mezcla de aire y combustible)
            BajarPiston();

            anguloCiguenal = SumarAngulo(anguloCiguenal, 180);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 90);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas);

            Console.WriteLine("Valvula de admision abierta: " + valvulaAdmisionAbierta);
            Console.WriteLine("Valvula de escape abierta: " + valvulaEscapeAbierta + "\n");
        } 

Finalmente, codificamos el propio algoritmo, de carácter público, que se encargará de invocar todos los pasos en un orden determinado:

        // Método público que ejecutará el algoritmo completo
        public void RealizarFaseMotor()
        {
            Admision();             // Parcialmente implementado en la clase base
            Compresion();           // Implementado en la clase base
            ConsumirCombustible();  // Delegado en las clases hijas
            Escape();               // Implementado en la clase base
        }

La clase completa, por lo tanto, tendrá el siguiente aspecto:

Motor.cs

    public abstract class Motor
    {
        // Estado de las válvulas
        private bool valvulaAdmisionAbierta = false;
        private bool valvulaEscapeAbierta = false;

        // Ángulos del cigueñal y del árbol de levas
        protected int anguloCiguenal = 0;
        protected int anguloArbolLevas = 0;

        // Método público que ejecutará el algoritmo completo
        public void RealizarFaseMotor()
        {
            Admision();             // Parcialmente implementado en la clase base
            Compresion();           // Implementado en la clase base
            ConsumirCombustible();  // Delegado en las clases hijas
            Escape();               // Implementado en la clase base
        }

        // Primera Fase: Admisión
        protected void Admision()
        {
            Console.WriteLine("COMENZANDO FASE DE ADMISION");

            // Se abre la válvula de admisión y se cierra la válvula de escape
            valvulaAdmisionAbierta = true;
            valvulaEscapeAbierta = false;

            // Se baja el pistón. Esta operación será distinta en el motor diesel (que
            // inyectará aire) o gasolina (que inyectará una mezcla de aire y combustible)
            BajarPiston();

            anguloCiguenal = SumarAngulo(anguloCiguenal, 180);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 90);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas);

            Console.WriteLine("Valvula de admision abierta: " + valvulaAdmisionAbierta);
            Console.WriteLine("Valvula de escape abierta: " + valvulaEscapeAbierta + "\n");
        }

        // La bajada del pistón depende del motor concreto, por lo que deberá ser implementada
        // por la clase hija.
        protected abstract void BajarPiston();

        // Segunda Fase: Compresión
        protected void Compresion()
        {
            Console.WriteLine("COMENZANDO FASE DE COMPRESION");

            // Se cierra la válvula de admisión
            valvulaAdmisionAbierta = false;

            // Giros del cigueñal y del árbol de levas
            anguloCiguenal = SumarAngulo(anguloCiguenal, 360);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 180);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas);

            Console.WriteLine("Valvula de admision abierta: " + valvulaAdmisionAbierta);
            Console.WriteLine("Valvula de escape abierta: " + valvulaEscapeAbierta + "\n");
        }

        // Tercera Fase: Consumo del combustible. Dado que depende del motor concreto,
        // este método será abstracto y deberá ser implementado por la clase derivada.
        protected abstract void ConsumirCombustible();

        // Cuarta Fase: Escape
        protected void Escape()
        {
            Console.WriteLine("COMENZANDO FASE DE ESCAPE");

            // Se abre la válvula de escape
            valvulaEscapeAbierta = true;

            // Giros del cigueñal y del árbol de levas
            anguloCiguenal = SumarAngulo(anguloCiguenal, 180);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 90);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas);

            Console.WriteLine("Gases expulsados. Fin de ciclo");
        }

        // Método que mantendrá el ángulo entre 0 y 359 grados
        protected int SumarAngulo(int anguloActual, int cantidad)
        {
            if (anguloActual + cantidad >= 360)
                return anguloActual + cantidad - 360;
            else
                return anguloActual + cantidad;
        }
    }

Una vez que tenemos la clase padre, implementaremos las clases derivadas: MotorGasolina y MotorDiesel. Únicamente tendrán que implementar las partes específicas, es decir, los métodos BajarPiston() y ConsumirCombustible():

MotorGasolina.cs

    public class MotorGasolina : Motor
    {
        protected override void BajarPiston()
        {
            Console.WriteLine("Inyectando aire y combustible en el motor");
        }

        public override void ConsumirCombustible()
        {
            Console.WriteLine("COMENZANDO FASE DE EXPLOSIÓN");

            Console.WriteLine("Iniciando chispa en la bujía");
            Console.WriteLine("La explosión provoca el movimiento del pistón");

            anguloCiguenal = SumarAngulo(anguloCiguenal, 180);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 90);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas + "\n");  
        }
    }

MotorDiesel.cs:

    public class MotorDiesel : Motor
    {
        protected override void BajarPiston()
        {
            Console.WriteLine("Inyectando aire en el motor");
        }

        protected override void ConsumirCombustible()
        {
            Console.WriteLine("COMENZANDO FASE DE COMBUSTIÓN");

            Console.WriteLine("Inyectando combustible pulverizado en el motor");
            Console.WriteLine("La presión provoca el movimiento del pistón");

            anguloCiguenal = SumarAngulo(anguloCiguenal, 180);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 90);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas + "\n");            
        }
    }

Tal y como hemos dicho, las dos diferencias entre ambos radican en la compresión (inyección de mezcla en el motor gasolina por inyección de aire en el motor diesel) y en el consumo de combustible (explosión en el motor gasolina por combustión en el motor diesel). Salvando los detalles concretos que hemos codificado, el algoritmo del motor es exactamente el mismo, y viene determinado por el método público codificado en la clase base RealizarFaseMotor(). De hecho, si usamos el método para comprobar el funcionamiento de ambos motores, veremos el resultado:

            Motor mGasolina = new MotorGasolina();
            Motor mDiesel = new MotorDiesel();

            mGasolina.RealizarFaseMotor();
            Console.WriteLine("----------------------------------------------------");
            mDiesel.RealizarFaseMotor();

Algoritmos con gancho

Lo que hemos visto hasta ahora es sencillo de entender y de implementar, pero probablemente nos hayamos dado cuenta de un pequeño detalle: es demasiado rígido. La idea de mantener encapsulado e inmutable el cuerpo del algoritmo evita efectos indeseados, pero limita muchísimo la posibilidad de añadir pasos intermedios. Por ejemplo, ¿qué ocurriría si nuestro motor fuera turbo? El turbo realiza una compresión del aire antes de introducirlo en la cámara de explosión, proporcionando una mayor potencia sin modificar la cilindrada del motor. Sin embargo, este paso estaría (que me disculpen los profesionales del motor por lo que voy a decir) justo antes de la admisión. Sin embargo… habrá motores que implementen turbo y que no lo implementen. ¿Creamos por tanto una clase MotorTurboGasolina y MotorTurboDiesel? ¿Hacemos también abstracto el método Admisiónpara que este funcionamiento pueda personalizarse en las clases hijas? No es necesario. Para este tipo de situaciones, el patrón proporciona lo que se conocen como Hooks, métodos de enganche o ganchos.

La filosofía de estos métodos es sencilla: se implementan en la clase base con un comportamiento por defecto, que puede ser sobrecargado en las clases derivadas o ejecutado como está. De este modo, se proporcionan pasos opcionales, haciendo que las clases derivadas enganchen funcionalidad opcional en ciertos puntos del algoritmo. Estos hooks suelen utilizarse normalmente con cláusulas condicionales, de forma que se ejecuten en ciertas condiciones concretas.

En nuestro caso, añadiríamos un nuevo paso a nuestro algoritmo, al que llamaríamos ComprimirTurbo(), que implementaríamos en la clase con un comportamiento por defecto:

        protected virtual void ComprimirTurbo()
        {
            Console.WriteLine("Turbo no presente");
        }
        // Método público que ejecutará el algoritmo completo
        public void RealizarFaseMotor()
        {
            ComprimirTurbo();       // Hook (método opcional)
            Admision();             // Parcialmente implementado en la clase base
            Compresion();           // Implementado en la clase base
            ConsumirCombustible();  // Delegado en las clases hijas
            Escape();               // Implementado en la clase base
        }

Al ser declarado como virtual, el método puede ser sobrecargado en las clases derivadas. Así, modificaremos nuestro motor diesel para que permita instanciar un motor turbo de la siguiente manera:

    public class MotorDiesel : Motor
    {
        private bool turbo = false;

        public MotorDiesel(bool turbo)
        {
            this.turbo = turbo;
        }

        protected override void ComprimirTurbo()
        {
            // Si el coche es turbo, ejecutará su propio código. En caso contrario, efectuará
            // la operación por defecto
            if (turbo)
                Console.WriteLine("Comprimiendo aire en el turbo antes de la admisión");
            else
                base.ComprimirTurbo();
        }

        protected override void BajarPiston()
        {
            Console.WriteLine("Inyectando aire en el motor");
        }

        protected override void ConsumirCombustible()
        {
            Console.WriteLine("COMENZANDO FASE DE COMBUSTIÓN");

            Console.WriteLine("Inyectando combustible pulverizado en el motor");
            Console.WriteLine("La presión provoca el movimiento del pistón");

            anguloCiguenal = SumarAngulo(anguloCiguenal, 180);
            anguloArbolLevas = SumarAngulo(anguloArbolLevas, 90);

            Console.WriteLine("Angulo del ciguenal: " + anguloCiguenal);
            Console.WriteLine("Angulo del arbol de levas: " + anguloArbolLevas + "\n");            
        }
    }

El motor gasolina no será modificado, de modo que ejecutará el método por defecto (no se «enganchará» al método ComprimirTurbo). Si ahora modificamos nuestro programa para instanciar un motor diesel turbo de la siguiente manera:

            Motor mGasolina = new MotorGasolina();
            Motor mDiesel = new MotorDiesel(true);

            mGasolina.RealizarFaseMotor();
            Console.WriteLine("----------------------------------------------------");
            mDiesel.RealizarFaseMotor();

Veremos que el motor diesel hace uso del gancho para añadir su propia funcionalidad, mientras que el motor gasolina ha delegado en la clase base el funcionamiento por defecto:

¿Cuándo utilizar este patrón? Ejemplos reales

Este patrón es aconsejable en los siguientes supuestos:

• Cuando se cuenta con un algoritmo aplicable a varias situaciones, cuya implementación difiere únicamente en algunos pasos.
• Arquitecturas donde los pasos de un proceso estén definidos (el qué), pero sea necesario establecer los detalles sobre cómo realizarlos (el cómo).
• Módulos en los que exista una gran cantidad de código duplicado que pueda ser factorizado en pasos comunes.

Uno de los ejemplos más claros del uso de este patrón se da en los Servlets de Java. En ellos se produce una invocación secuencial de los métodos init() (al instanciar el Servlet) y service() (al realizar una petición) que, a partir del tipo de petición, ejecutarán el método correspondiente a su tipo, como doGet(), doPost()… Estos métodos son los que el programador deberá implementar para darles una funcionalidad concreta.

Otro ejemplo podría ser la ejecución de una transacción en base de datos: los pasos estarán bien definidos (apertura de la conexión, ejecución de la consulta, procesamiento de los datos, compromiso de la operación y cierre de la conexión), pero la implementación de éstos podría variar (por ejemplo, dependiendo de la base de datos a la cual se pretenda conectar).

Fuentes:

• Head First Design Patterns (Freeman et al.)
• Template Method (doFactory.com)
• Design Patterns Uncovered: The Template Method Pattern (James Sugrue, dzone.com)

«Encapsular una petición como un objeto, de modo que puedan parametrizarse otros objetos con distintas peticiones o colas de peticiones y proporcionar soporte para realizar operaciones que puedan deshacerse».

Design Patterns: Elements of Reusable Object-Oriented Software

Cuando decimos que un patrón es «estructural» es sencillo imaginar que su cometido será modelar las clases de tal forma que cumplan un cometido concreto. Sin embargo, el concepto de diseñar clases orientando su funcionalidad hacia el comportamiento es algo más complicado. El patrón command u orden (como decía mi profesor de programación en primero de carrera, command se debería traducir por órden, no por comando, ya que un comando es un señor militar que pega tiros en la selva) tiene como objetivo encapsular la invocación de un método. Dicho así sin más, suena sencillo de entender pero… ¿cómo lo implementamos? La definición, a diferencia del patrón anterior, es un conglomerado de términos incomprensibles, ¿verdad? Encapsular una petición como un objeto. Vale, lo pillo. Pero ¿parametrizarse? ¿Soporte para realizar peticiones que puedan deshacerse?

Entendiendo el patrón Command

A estas alturas ya deberíamos de estar saturados del concepto de depender de abstracciones, no de concreciones. Y por ello, seguramente nos sea mucho más sencillo entender este patrón si lo adaptamos a un lenguaje más técnico y algo menos abstracto (principal objetivo de esta serie de artículos). Si hacemos aterrizar este concepto al mundo real, podríamos traducirlo como lo siguiente:

«Utilizar una interfaz con un método genérico de modo que los objetos que la implementen incluyan una referencia al objeto cuyo método queremos abstraer. Al invocar el método genérico se invocará este método, por lo que el objeto receptor no tiene por qué conocer el objeto original, bastándole una referencia a la interfaz para ejecutar el método«.

¿Mejor así? Quizás sea todavía un poco complicado, ¿verdad? Intentemos desgranarlo un poco más.

Si tenemos una interfaz común ICommand con un método genérico execute(), cualquier objeto que la implemente podrá añadir dentro del código de execute() la llamada al método que queremos abstraer. De este modo, el objeto receptor queda completamente desacoplado del objeto invocado. Le bastará con invocar ICommand.execute() para que ocurra la magia. El cliente será el encargado de implementar las clases adecuadas para asegurar la funcionalidad que el objeto receptor espera. Nuestro objeto receptor puede ser una aplicación web esperando ejecutar una operación sobre una base de datos. Lo ideal sería que nuestra aplicación no tuviera que preocuparse ni qué objeto usar para realizar la operación ni el nombre de ésta. Si la interfaz ICommand proporciona un método genérico para realizar esta operación, nuestros programadores podrán implementar tantos conectores a distintas bases de datos como quieran. Nuestra aplicación simplemente dirá algo así como «a mí no me cuentes tu vida. No me interesa saber qué hay más allá, yo ejecutaré el método ICommand.execute() y tú te encargas del resto del trabajo«.

Por lo tanto, podemos afirmar que el patrón Command es la quintaesencia de una interfaz: ofrece la firma de un método genérico que las clases que la implementan se encargarán de completar. Resumiendo, el patrón Command hace que la implementación del método de una interfaz encapsule la invocación del método de otro objeto distinto.

Si nos centramos en el diagrama de clases del diseño del patrón, podremos identificar los siguientes actores:

• ICommand: interfaz que expone el método genérico (execute()).
• CommandGenerico: implementa ICommand y posee una referencia al objeto cuyo método execute() tendrá que encapsular. Este objeto recibe el nombre de Receiver.
• Receiver: como acabamos de decir, es el objeto que implementa la funcionalidad real. Alguno de sus métodos será encapsulado por ICommand.execute().
• Invoker: clase encargada de invocar el método ICommand.execute(). Posee una referencia (o varias) a ICommand, y su método SetCommand le permite cambiar su funcionalidad en tiempo de ejecución. Ofrecerá también un método que invoque el método ICommand.Execute() que, a su vez, invocará Receiver.MetodoAEncapsular().

Implementando el patrón Command

Volvamos a nuestra fábrica de vehículos. Se nos ha encargado programar parte de la centralita de un nuevo modelo, concretamente de la activación y desactivación de las luces. Sabemos que contaremos con tres tipos de luces: posición, cortas y largas, pero la implementación de los métodos encargados de este proceso aún no están definidas, ya que se han subcontratado a una empresa coreana. Sin embargo, nuestro cliente nos exige que, pese a ello, debemos avanzar con el diseño de este módulo.

El patrón Command es perfecto en este escenario: contamos con un entorno en el que debemos ejecutar un método que aún no conocemos o que puede cambiar con el tiempo, por lo que crearemos una interfaz ICommand que exponga un método Execute(). Posteriormente, una vez que los requisitos estén claros y que sepamos qué hay que ejecutar, implementaremos clases que se acoplen entre nuestra centralita y el componente que la empresa coreana nos proporcionará.

Por lo tanto, comenzaremos creando una interfaz ICommand que se encargará de ofrecer una firma para el método que encapsulará el resto de los métodos: Execute():

    public interface ICommand
    {
        // El método Execute() será aquel que el objeto que reciba la referencia
        // será capaz de ejecutar.
        void Execute();
    }

A continuación modelaremos las clases que serán encapsuladas por el objeto Command. O más específicamente, las clases cuyos métodos serán encapsulados por el método Execute() del objecto Command(). Crearemos una clase abstracta de la que heredarán el resto de las clases que serán encapsuladas, aunque en realidad esto no es estrictamente necesario (un objeto Command podría albergar diversos objetos no necesariamente relacionados entre sí). Esta clase es conocida como Receiver, y se caracteriza porque se encargará de albergar la lógica concreta del método. Si nos ceñimos a la descripción de una interfaz, la clase Receiver sería aquella clase que se encargaría de implementarla.

LucesReceiver.cs

    // Clase abstracta de la que heredarán las clases que serán encapsuladas por los
    // objectos Command. Por lo tanto, sus métodos serán aquellos que encapsulará el
    // método Execute().
    public abstract class LucesReceiver
    {
        protected bool encendidas;
        protected int distanciaAlumbrado;

        // Propiedad de sólo lectura que devolverá el estado de las luces
        public bool Encendidas
        {
            get {return encendidas;}
        }

        // Método encargado de apagar las luces. Establece el estado del atributo 'encendidas'
        // a 'false'. Será común a todas las clases que hereden de ella.
        public void Apagar()
        {
            this.encendidas = false;
        }

        // El método Encender será distinto en cada una de las clases que hereden de esta clase.
        public abstract int Encender();
    }

A continuación implementaremos las clases concretas cuyos métodos serán encapsulados por ICommand.Execute(). Dado que heredan de la clase abstracta LucesReceiver, únicamente tendremos que implementar de forma explícita el método Encender(), ya que el resto de la funcionalidad será común. Comenzaremos por las luces de posición:

LucesPosicion.cs

    public class LucesPosicion : LucesReceiver
    {
        private const int DISTANCIA = 1;

        public override int Encender()
        {
            this.encendidas = true;
            return DISTANCIA;
        }
    }

A continuación hacemos lo mismo con las luces cortas.

LucesCortas.cs

    public class LucesCortas : LucesReceiver
    {
        private const int DISTANCIA = 40;

        public override int Encender()
        {
            this.encendidas = true;
            return DISTANCIA;
        }
    }

Finalmente, realizamos el mismo proceso con las luces largas.

LucesLargas.cs

    public class LucesLargas : LucesReceiver
    {
        private const int DISTANCIA = 200;

        public override int Encender()
        {
            this.encendidas = true;
            return DISTANCIA;
        }
    }

Esto se resumiría ahora mismo en el siguiente esquema:

Ya tenemos implementado uno de los elementos de nuestro patrón. Ahora haremos lo propio con la parte cliente, es decir, nuestra centralita. O más concretamente, el módulo encargado de encender y apagar las luces. Este se corresponderá con el elemento Invoker, que es aquel que tendrá como objetivo invocar la acción encapsulada por el objeto Command. Comenzaremos implementando una interfaz que ofrezca dos operaciones:

• Una operación SetCommand(ICommand) que permitirá a nuestro módulo cambiar el ICommand a ejecutar.
• Una operación Invoke() que invoque el método ICommand.Execute() que esté asignado en el momento actual.

IInvoker.cs

    public interface IInvoker
    {
        // Inyecta un ICommand, permitiendo cambiar la operación encapsulada en
        // tiempo de ejecución
        void SetCommand(ICommand command);

        // Ejecuta el método encapsulado
        void Invoke();
    } 

A continuación implementaremos la interfaz. Lo haremos a través de la clase ControladorLucesInvoker. Nuestra clase realizará justo aquello que acabamos de definir en la interfaz. Además, incluirá una referencia a un objeto que implemente la interfaz ICommand

    public class ControladorLucesInvoker : IInvoker
    {
        ICommand command;

        public void SetCommand(ICommand command)
        {
            this.command = command;
        }

        public void Invoke()
        {
            command.Execute();
        }
    }

Ya casi hemos completado nuestro patrón. Falta lo más importante: las clases que implementan la clase ICommand y que simbolizan las operaciones que se quieren encapsular. Estas operaciones serán, como podemos imaginar, encender y apagar. Por lo tanto, crearemos las clases EncenderLucesCommand
y ApagarLucesCommand:

EncenderLucesCommand.cs

    public class EncenderLucesCommand : ICommand
    {
        // Referencia al objeto cuyo método se quiere encapsular
        private LucesReceiver luces;

        // El constructor inyectará el objeto cuyo método se quiere encapsular
        public EncenderLucesCommand(LucesReceiver luces)
        {
            this.luces = luces;
        }

        // El método Execute() ejecutará el método encapsulado
        public void Execute()
        {
            int distancia = luces.Encender();
            Console.WriteLine(string.Format("Encendiendo luces. Alumbrando a una distancia de {0} metros.", distancia));
        }
    }

La clase ApagarLucesCommand realizará la operación contraria.

ApagarLucesCommand.cs

    public class ApagarLucesCommand : ICommand
    {
        private LucesReceiver luces;

        public ApagarLucesCommand(LucesReceiver luces)
        {
            this.luces = luces;
        }

        public void Execute()
        {
            luces.Apagar();
            Console.WriteLine("Apagando las luces");
        }
    }

Esto completará nuestro diagrama de clases, dejándolo de la siguiente manera:

Finalmente, añadimos el código que hará uso del patrón que acabamos de implementar. En él crearemos los tres tipos de luces (posición, cortas y largas) y utilizaremos el método SetCommand() de cada uno de los objetos destinados a encender y a apagar las luces para cambiar en tiempo de ejecución el tipo de luz a manejar.

            // Instanciamos los objetos cuyos métodos serán encapsulados dentro de
            // objetos que implementan ICommand
            LucesReceiver lucesPosicion = new LucesPosicion();
            LucesReceiver lucesCortas = new LucesCortas();
            LucesReceiver lucesLargas = new LucesLargas();

            // Creamos los objetos Command que encapsulan los métodos de las clases anteriores
            ICommand encenderPosicion = new EncenderLucesCommand(lucesPosicion);
            ICommand apagarPosicion = new ApagarLucesCommand(lucesPosicion);

            ICommand encenderCortas = new EncenderLucesCommand(lucesCortas);
            ICommand apagarCortas = new ApagarLucesCommand(lucesCortas);

            ICommand encenderLargas = new EncenderLucesCommand(lucesLargas);
            ICommand apagarLargas = new ApagarLucesCommand(lucesLargas);

            // Creamos un nuevo Invoker (el objeto que será desacoplado de las luces)
            IInvoker invoker = new ControladorLucesInvoker();

            // Le asociamos los objetos Command y los ejecutamos
            // El objeto invoker invoca el método 'Execute()' sin saber en ningún momento
            // qué es lo que se está ejecutando realmente.
            invoker.SetCommand(encenderPosicion);      // Asociamos el ICommand
            invoker.Invoke();                          // Hacemos que se ejecute ICommand.Execute()

            // Realizamos lo mismo con el resto de instancias que implementan ICommand.
            // Como podemos ver, el ICommand puede asignarse en tiempo de ejecucion
            invoker.SetCommand(apagarPosicion);
            invoker.Invoke();

            // Luces cortas
            invoker.SetCommand(encenderCortas);
            invoker.Invoke();

            invoker.SetCommand(apagarCortas);
            invoker.Invoke();

            // Luces largas
            invoker.SetCommand(encenderLargas);
            invoker.Invoke();

            invoker.SetCommand(apagarLargas);
            invoker.Invoke();

El resultado de ejecutar este código será el siguiente:

¿Cuándo utilizar este patrón? Ejemplos reales

Dado que este patrón nos permite encapsular la ejecución de un método como un objeto, una de las funcionalidades que nos ofrece este patrón es la de encadenar invocaciones. Si creamos una serie de objetos de este tipo y los almacenamos como objetos, éstos pueden pasarse como parámetros a un método que los vaya ejecutando de forma secuencial.

El segundo escenario en el que este patrón es útil es aquel que hemos visto en el ejemplo, es decir, aquel en el que el invocador del método deba ser desacoplado del objeto que maneja la invocación. Esto puede darse por necesidades del diseño o bien porque las especificaciones del módulo que maneja la invocación no estén definidas o existe previsión de que vaya a variar con el tiempo.

Recordemos además que la definición del patrón establecía que debía proporcionar soporte para deshacer operaciones. ¿Cómo realizar esto? Dado que estas operaciones se encapsulan como objetos, sería perfectamente posible mantener en memoria una pila con elementos ejecutados y otra que almacene objetos que modelen los distintos estados correspondientes a los instantes anteriores a ejecutar cada uno de los Commands de la primera pila. De este modo, realizar la opción deshacer sería tan sencillo como realizar un pop del primer objeto de cada pila y sobreescribir el estado actual del programa con el contenido del primer objeto almacenado en la pila de estados.

Otros ejemplos reales de este patrón serían, por ejemplo:

• Grabación de macros (secuencia de operaciones)
• Asistentes de instalación (cada pantalla implementaría un Command que realizaría una operación Execute() al pulsar el botón «Siguiente»)
• Elementos Action del framework Swing de Java.

Fuentes:

• Head First Design Patterns (Freeman et al.)
• Understanding and Implementing Command Pattern in C# (Rahul Rajat Singhj, CodeProject)

«Proporcionar una forma de acceder a los elementos de un objeto agregado de forma secuencial sin exponer sus detalles».

Design Patterns: Elements of Reusable Object-Oriented Software

Pese a que no seamos conscientes de ello, cuando programamos utilizamos el patrón Iterator a diario. Casi todas las estructuras de datos que representan colecciones utilizan de algún modo este patrón para proporcionar acceso secuencial a los elementos que las conforman, y tanto Java como .NET ofrecen interfaces que nos invitan a implementar este patrón codificando su comportamiento.

Ojo al detalle: hemos dicho recorrer secuencialmente, esto es, hacer uso de un proceso que sea capaz de situarse en el primer elemento de una colección y obtener la información de ese contenido. Tras esto, dado que hemos dicho que se trata de una operación secuencial, deberemos ser capaces de pasar del elemento actual al elemento al siguiente, obteniendo también su contenido. Por último, será necesario implementar algún mecanismo que nos informe si hemos alcanzado el final de la colección para detener el proceso de iteración.

Por lo tanto, el patrón Iterator debe proporcionar la siguiente funcionalidad:

• Obtener una referencia al elemento actual de la colección.
• Obtener una referencia al siguiente elemento de la colección (el situado a continuación del elemento actual).
• Obtener información sobre si existen más elementos después del actual.
• Reiniciar la colección para que el iterador apunte nuevamente al primer elemento de la colección.

Seguramente podremos pensar que no tiene mucho sentido implementar nuestro propio patrón Iterator, ya que prácticamente todas las colecciones implementan todas estas operaciones (e incluso alguna más). Sin embargo, existirán muchos supuestos en los que nos será útil.

Comencemos por el principio. Imaginemos que disponemos de una fábrica de vehículos. Esta fábrica guarda un registro pormenorizado de los vehículos que fabrica, que están modelados a través de la siguiente clase:

    public class Vehiculo
    {
        public string Marca { get; set; }
        public string Modelo { get; set; }
        public DateTime FechaFabricacion { get; set; }
        public double Precio { get; set; }

        public Vehiculo(string marca, string modelo, 
            DateTime fechaFabricacion, double precio)
        {
            this.Marca = marca;
            this.Modelo = modelo;
            this.FechaFabricacion = fechaFabricacion;
            this.Precio = precio;
        }

        public string CaracteristicasVehiculo()
        {
            return Marca + " " + Modelo + " fabricado en " +
                FechaFabricacion.ToShortDateString() + " con un precio de " +
                Precio + " euros.\n";
        }
    }

Como nuestros ingenieros han sido previsores, han decidido que la estructura de datos en la cual se almacenarán los vehículos implemente una interfaz, a la que llamaremos IRegistroVehiculos. Esta interfaz definirá las operaciones básicas que se harán sobre el registro, que serán insertar un nuevo vehículo y mostrar información sobre éste (un ejemplo más completo también incluiría métodos para eliminar y modificar, pero nos centraremos de momento en esta funcionalidad básica para no desviarnos del ejemplo):

    public interface IRegistroVehiculos
    {
        void InsertarVehiculo(string marca, string modelo, double precio);
        Vehiculo MostrarInformacionVehiculo(int indice);
    }

Nuestra fábrica de vehículos posee un sistema de gestión que almacena los vehículos en una estructura de datos agregada, como por ejemplo un ArrayList. Nuestra clase, como podremos imaginar, implementará la interfaz IRegistroVehiculos:

    public class RegistroVehiculos : IRegistroVehiculos
    {
        private ArrayList listaVehiculos;

        public RegistroVehiculos()
        {
            this.listaVehiculos = new ArrayList();
        }

        public void InsertarVehiculo(string marca, string modelo, double precio)
        {
            Vehiculo v = new Vehiculo(marca, modelo, DateTime.Now, precio);
            listaVehiculos.Add(v);
        }

        public Vehiculo MostrarInformacionVehiculo(int indice)
        {
            return (Vehiculo)listaVehiculos[indice];
        }
    }

Iterator entra en escena

Hasta ahora hemos creado una clase que contendrá la información sobre los vehículos y otra que contendrá un listado de éstos y será capaz de añadir nuevos vehículos y recuperar un vehículo del cual le pasaremos un índice. Sin embargo, aún no hemos visto ni rastro del patrón Iterator por ningún sitio. Este patrón es, precisamente, la pieza que nos falta para que nuestro modelo esté completo. Si al método MostrarInformacionVehiculo le pasamos un índice mayor que el número de elementos que contenga el ArrayList, lo que obtendremos será una bonita excepción de índice fuera de rango. Una posible solución sería comprobar dentro del método que el número de elementos menos uno es siempre mayor o igual que el índice pasado como parámetro, pero esto no arreglaría el problema: necesitamos una estructura que sea capaz de iterar sobre la colección e informar al cliente si existen más elementos disponibles. Es hora de implementar un iterador.

Para esta implementación utilizaremos, nuevamente, una interfaz que definirá las operaciones que tendrá que realizar. Estas operaciones ya las hemos definido al principio del artículo: un método que «reinicie» el interador colocándolo en el primer elemento, otro que devuelva el elemento actual, otro que nos devuelva el siguiente elemento (incrementando el índice en una unidad) y otro que nos informe si quedan elementos disponibles en la colección:

    public interface IIteratorVehiculo
    {
        void Primero();
        Vehiculo Actual();
        Vehiculo Siguiente();
        bool QuedanElementos();
    }

Comencemos a implementar nuestro iterador. Además de heredar de IIteratorVehiculo, deberá contener una referencia al listado completo de elementos del ArrayList. El método para realizar esta operación, como habremos podido imaginar, se realizará inyectándolo a través del constructor. Además, añadiremos una variable entera que se ocupe de almacenar el índice del elemento en el que se encuentra el iterador en este momento.

    public class IteratorVehiculo : IIteratorVehiculo
    {
        // Referencia al listado completo
        private ArrayList vehiculos;

        // Almacenaremos el índice en el que se encuentra el iterador
        private int posicionActual = -1;

        // El constructor inyectará el ArrayList en el objeto
        public override IteratorVehiculo(ArrayList listado)
        {
            this.vehiculos = listado;
        }
    }

Hemos inicializado la variable posicionActual al valor -1, lo cual implica que nuestro iterador se encuentra en la posición inmediatamente anterior a la primera posición. El método Primero(), de hecho, debería realizar esta misma operación:

        // Operación 1: Reinicio del índice, colocándolo en el elemento anterior al primero
        public void Primero()
        {
            this.posicionActual = -1;
        }

Espera, espera, ¿Por qué colocarlo antes del primer elemento en lugar de referenciar directamente el primer elemento? ¿No sería más intuitivo? Sí, pero sería erróneo. Si el método Primero() colocara el cursor en el primer elemento, ¿qué ocurriría si la lista estuviera vacía? Exacto: estaríamos referenciando un elemento que no existe, y lo que es peor: no tendríamos modo alguno de que nuestro iterador nos informara si existen elementos, ya que el método QuedanElementos(), encargado de esta operación, no podría actuar sobre el primer elemento de la colección. Colocando el índice en el elemento inmediatamente anterior solucionaríamos directamente estos dos problemas.

Lo siguiente que haremos será codificar el método Actual(), que nos devolverá una referencia al elemento cuyo índice se corresponda con el almacenado en posicionActual(), realizando, eso sí, las comprobaciones pertinentes.

        // Operación 2: Acceso al elemento actual
        public Vehiculo Actual()
        {
            // Si no existen elementos, devolveremos null.
            // Si el indice actual es mayor que el mayor indice aceptable, devolveremos null.
            // Si el indice actual es -1, devolveremos null.
            if ((this.vehiculos == null) || 
                (this.vehiculos.Count == 0) || 
                (posicionActual > this.vehiculos.Count - 1) ||
                (this.posicionActual < 0))
                return null;

            // Devolvemos el elemento correspondiente al elemento actual
            else
                return (Vehiculo)this.vehiculos[posicionActual];
        }

Como el índice puede ser -1, será también necesario controlar esta posibilidad.

La siguiente operación nos ofrecerá una referencia al elemento siguiente, incrementando el índice en una unidad.

        // Operación 3: Acceso al siguiente elemento
        public Vehiculo Siguiente()
        {
            // Si no existen elementos, devolveremos null.
            // Si el indice siguiente es mayor que el mayor indice aceptable, devolveremos null.
            if ((this.vehiculos == null) || 
                (this.vehiculos.Count == 0) || 
                (posicionActual + 1 > this.vehiculos.Count - 1))
                return null;

            // Aumentamos el índice en una unidad y devolvemos ese elemento
            else
                return (Vehiculo)this.vehiculos[++posicionActual];
        }

Finalmente, el método QuedanElementos() comprobará si nos encontramos en el último elemento del listado o si, por el contrario, aún quedan elementos disponibles.

        // Operación 4: Comprobación de si existen elementos en la colección
        public bool QuedanElementos()
        {
            // Devolvemos un booleano que será true si la posición siguiente es menor o igual que el
            // máximo índice aceptable (número de elementos del array - 1).
            return (posicionActual + 1 <= this.vehiculos.Count - 1);
        }

Et voilà! Ya tenemos listo nuestro Iterator. Únicamente nos queda algo por hacer: proporcionar a nuestro listado RegistroVehiculos un método que nos genere un Iterator listo para ser utilizado con la colección contenida dentro de él. Es más, ya que tenemos disponibles sus respectivas abstracciones (las interfaces IRegistroVehiculos e IIteratorVehiculo), añadiremos un método a IRegistroVehiculo una función que nos devuelva una referencia a la interfaz IIteratorVehiculo, que será implementada por RegistroVehiculos. Por lo tanto, nuestra interfaz IRegistroVehiculos tendrá el siguiente aspecto definitivo:

    public interface IRegistroVehiculos
    {
        void InsertarVehiculo(string marca, string modelo, double precio);
        Vehiculo MostrarInformacionVehiculo(int indice);
        IIteratorVehiculo ObtenerIterator();
    }

El método correspondiente dentro de RegistroVehiculos se limitará a instanciar un objeto de la clase IteratorVehiculo (que recordemos que implementaba IIteratorVehiculo) inyectándole el ArrayList, devolviendo el objeto como resultado de la función.

        public IIteratorVehiculo ObtenerIterator()
        {
            return new IteratorVehiculo(listaVehiculos);
        }

Para probar el resultado de nuestro patrón, nos bastará el siguiente ejemplo:

            // Declaramos el registro
            IRegistroVehiculos registro = new RegistroVehiculos();

            // Insertamos unos cuantos elementos
            registro.InsertarVehiculo("Volkswagen", "Polo", 12300);
            registro.InsertarVehiculo("Volkswagen", "Golf GTI", 18900);
            registro.InsertarVehiculo("Volkswagen", "Passat", 27000);
            registro.InsertarVehiculo("Volkswagen", "Scirocco", 32100);
            registro.InsertarVehiculo("Volkswagen", "Touareg", 21800);

            // Obtenemos el iterator
            IIteratorVehiculo iterador = registro.ObtenerIterator();

            // Mientras queden elementos
            while (iterador.QuedanElementos())
            {
                // Obtenemos el siguiente elemento
                Vehiculo v = iterador.Siguiente();

                // Mostramos su contenido
                Console.WriteLine(v.Marca + " " + v.Modelo + " fabricado el " + v.FechaFabricacion.ToShortDateString() + " (" + v.Precio + " euros)");
            }

Esto nos proporcionará la siguiente salida:

Aplicación del patron Iterator

Este patrón, como podemos ver, no tiene demasiada complejidad: es más simple que la maquinaria de un chupete. Sin embargo, la pregunta que seguramente ronde la cabeza del lector sea similar a «pero si tenemos un ArrayList, ¿para qué recorrerlo secuencialmente? ¿Para qué usar esas comprobaciones cuando pueden codificarse en nuestro código de forma sencilla? ¿No es rizar el rizo? La verdad es que sí. Este patrón no está pensado para aplicarlo a una estructura de datos que ya posea mecanismos de acceso, como por ejemplo el ArrayList que hemos utilizado aquí: está pensado para ser utilizado en estructuras en los que el cliente no deba o no necesite conocer su estructura interna. Este ejemplo es estúpido porque hemos observado «las tripas» de la clase RegistroVehiculos y sabemos que dentro de ella vive un ArrayList. Pero si no lo supiéramos, el Iterator se encargaría de proporcionarnos acceso a sus miembros.

Vale, de acuerdo, en la ignorancia está la felicidad. Pero aún así, el programador original de la aplicación sabe que dentro de RegistroVehiculos hay un ArrayList, independientemente de que el cliente necesite saberlo o no. ¿Por qué complicarse la vida de esta manera? Porque ¿qué ocurriría si dentro de nuestra estructura de datos no hubiese un ArrayList. O mejor aún: ¿qué ocurriría si nuestro cliente abriese una fábrica en otra ciudad y nuestra aplicación necesitara conectarse de forma remota a la información allí contenida? ¿Cambiaríamos todas nuestras clases e interfaces para proporcionar un conjunto de operaciones que nos permitiera conectarnos de forma remota al nuevo centro? Con este patrón no sería necesario. Bastaría con implementar otra vez la interfaz IIteratorVehiculo de forma que sus operaciones realizaran las peticiones necesarias al servicio remoto, haciéndolo transparente para el usuario. Por ejemplo, podríamos idear una implementación como la siguiente:

    public class IteratorVehiculoRemoto : IIteratorVehiculo
    {

        private String urlServicio;

        // Almacenaremos el índice en el que se encuentra el iterador
        private int posicionActual = -1;

        // El constructor inyectará la dirección del servicio en el objeto
        public IteratorVehiculoRemoto(String urlServicio)
        {
            this.urlServicio = urlServicio;
        }

        #region IIteratorVehiculo Members

        public void Primero()
        {
            this.posicionActual = -1;
        }

        public Vehiculo Actual()
        {
            // Aquí realizaríamos las comprobaciones necesarias para determinar si la petición es válida
            // ...

            // Realizamos la petición HTTP
            WebRequest request = WebRequest.Create(urlServicio + "?Index=" + posicionActual);
            ((HttpWebRequest)request).UserAgent = "Cliente IteratorVehiculoRemoto";
            request.Method = "GET";

            // Obtenemos la respuesta
            WebResponse response = request.GetResponse();
            Stream data = response.GetResponseStream();
            response.Close();

            // Deserializamos el objeto
            byte[] buffer = new byte[data.Length];
            data.Read(buffer, 0, buffer.Length);
            MemoryStream ms = new MemoryStream(buffer);
            IFormatter formatter = new BinaryFormatter();
            ms.Seek(0, SeekOrigin.Begin);
            Vehiculo v = (Vehiculo)formatter.Deserialize(ms);

            return v;
        }

        public Vehiculo Siguiente()
        {
            // Aquí realizaríamos las comprobaciones necesarias para determinar si la petición es válida
            // ...

            // Realizamos la petición HTTP
            WebRequest request = WebRequest.Create(urlServicio + "?Index=" + (++posicionActual));
            ((HttpWebRequest)request).UserAgent = "Cliente IteratorVehiculoRemoto";
            request.Method = "GET";

            // Obtenemos la respuesta
            WebResponse response = request.GetResponse();
            Stream data = response.GetResponseStream();
            response.Close();

            // Deserializamos el objeto
            byte[] buffer = new byte[data.Length];
            data.Read(buffer, 0, buffer.Length);
            MemoryStream ms = new MemoryStream(buffer);
            IFormatter formatter = new BinaryFormatter();
            ms.Seek(0, SeekOrigin.Begin);
            Vehiculo v = (Vehiculo)formatter.Deserialize(ms);

            return v;
        }

        public bool QuedanElementos()
        {
            // Realizamos la petición HTTP
            WebRequest request = WebRequest.Create(urlServicio + "?GetMaxElements");
            ((HttpWebRequest)request).UserAgent = "Cliente IteratorVehiculoRemoto";
            request.Method = "GET";

            // Obtenemos la respuesta
            WebResponse response = request.GetResponse();
            Stream data = response.GetResponseStream();
            response.Close();

            // Obtenemos el resultado de la petición
            StreamReader reader = new StreamReader(data);
            string strResultado = reader.ReadLine();
            if(!string.IsNullOrEmpty(strResultado))
                return Boolean.Parse(strResultado);

            return false;
        }

        #endregion
    }

Como podemos ver, ambos iteradores serán IIteratorVehiculo, y como tales, tendrán los mismos métodos. Por lo tanto, la clase cliente no necesitará saber si está obteniendo los datos desde un ArrayList de nuestra máquina o desde un servicio web alojado en otra Comunidad Autónoma. La transparencia es la clave de este patrón, y por lo tanto, será el objetivo que debemos buscar. Incluso podríamos crear un tercer Iterator que de algún modo fusionara ambos iteradores, haciendo que cuando se llegara al final del iterador del ArrayList se comenzaran a proporcionar elementos del servicio web, tratando ambas colecciones de cara al cliente como si fuera una sola.
Nota: el código que he mostrado para simbolizar la implementación de un iterador ejecutado sobre un servicio no es real. Se trata de una simulación en la que se pretende mostrar, de forma conceptual, cómo podría implementarse el patrón para acceder a elementos remotos. Ningún servicio web ha sido maltratado durante la redacción de este artículo.

¿Cuándo utilizar este patrón? Ejemplos reales

Ya hemos visto cuándo es aconsejable utilizar este patrón: cuando queramos proporcionar una forma de iterar sobre una colección sin que el cliente tenga que conocer los detalles de cómo está implementada. Por fortuna para nosotros, no tendremos que crear una interfaz IIterator, ya que tanto Java como .NET ofrecen una interfaz estándar de la cual es aconsejable que hereden los iteradores que decidamos implementar. Estas clases son IEnumerator en el caso de .NET e Iterator en el caso de Java.
En el caso de .NET, la clase IEnumerator será la encargada de cumplir esta función. A diferencia del ejemplo anterior, no posee un método QuedanElementos(). Sin embargo, esta funcionalidad está cubierta por el método MoveNext(), que en lugar de devolver una referencia al elemento siguiente, comprueba si existen elementos y devuelve el resultado de la consulta. Además, en caso afirmativo, incrementará el índice en una unidad, permitiendo al método Current() acceder al siguiente elemento.

    private class IteratorVehiculoEnumerable<T> : IEnumerator<T>
    {
        // Referencia al listado completo
        private ArrayList listaElementos;

        // Almacenaremos el índice en el que se encuentra el iterador
        private int posicionActual = -1;

        // El constructor inyectará el ArrayList en el objeto
        public IteratorVehiculoEnumerable(ArrayList listaElementos)
        {
            this.listaElementos = listaElementos;
        }

        public void Reset()
        {
            this.posicionActual = -1;
        }

        // Devuelve el elemento actual
        public T Current
        {
            get 
            {
                // Si no existen elementos, devolveremos null.
                // Si el indice actual es mayor que el mayor indice aceptable, devolveremos null.
                // Si el indice actual es -1, devolveremos null.
                if ((this.listaElementos == null) ||
                    (this.listaElementos.Count == 0) ||
                    (posicionActual > this.listaElementos.Count - 1) ||
                    (this.posicionActual < 0))
                    return default(T);

                // Devolvemos el elemento correspondiente al elemento actual
                else
                    return (T)this.listaElementos[posicionActual];
            }
        }

        object IEnumerator.Current
        {
            get { return Current; }
        }

        // La función ElementoSiguiente() de IEnumerable, a diferencia del ejemplo anterior, no devuelve una
        // referencia al siguiente elemento, sino que detecta si existe otro elemento (lo que en la implementación
        // anterior realizaba QuedanElementos()) y en caso afirmativo, incrementa el índice, apuntando al siguiente
        // elemento, que será recuperado mediante Current.
        public bool MoveNext()
        {
            bool quedanElementos = (posicionActual + 1 <= this.listaElementos.Count - 1);
            if (quedanElementos)
                posicionActual++;

            return quedanElementos;
        }

        public void Dispose()
        {
            // Este método se implementará en caso de utilizar recursos no gestionados.
            // En ese caso, aquí se liberarán esos recursos antes de destruir el objeto.
            return;
        }
    }

Además de disponer de la interfaz IEnumerator, también disponemos de la interfaz IEnumerable, que serviría para implementar el registro de vehículos. Esta interfaz proporciona la función GetEnumerable(), que será la encargada de construir el IEnumerator correspondiente.
Por su parte, tal y como hemos dicho, Java proporciona su interfaz Iterator, que tiene el siguiente aspecto:

	public class IteratorVehiculo implements Iterator<Vehiculo> {

	@Override
	public boolean hasNext() {
		// TODO Auto-generated method stub
		return false;
	}

	@Override
	public Object next() {
		// TODO Auto-generated method stub
		return null;
	}

	@Override
	public void remove() {
		// TODO Auto-generated method stub
		
	}

Fuentes:

• Head First Design Patterns (Freeman et al.)
• A Beginner’s Tutorial on Implementing IEnumerable Interface and Understanding yield Keyword (Rahul Rajat Singh, Codeproject)

«Proporcionar un sustituto o intermediario para otro objeto de modo que pueda controlarse el acceso que se tiene hacia él».

Design Patterns: Elements of Reusable Object-Oriented Software

Supongo que todos conocemos el concepto de proxy, al menos en su acepción aplicada a la navegación web. Se trata de una máquina que actúa de intermediaria a la hora de servir páginas web (u otros servicios). En la configuración de área local podemos indicar la IP de esta máquina y será esta máquina la que se conecte a la URL por nosotros y la envíe a nuestro equipo.

De este modo, un equipo no se conectará directamente a la URL, sino que lo hará a través de este intermediario. ¿Por qué hacer esto? Por múltiples motivos: podemos, por ejemplo, restringir las URLs que nuestros clientes (ordenadores de la red local) pueden visitar. O cachear las páginas que se visitan con más frecuencia, haciendo innecesario el acceso a la web «real» en los casos en los que el acceso se repita, proporcionando un ahorro en ancho de banda. En resumen, un proxy será una entidad en la que delegaremos la ejecución de ciertas tareas y que decidirá, en última instancia, qué acciones realizar antes y después de éstas. Los proxies, por tanto, podrían dedicarse perfectamente a la política

Tipos de proxy

Dependiendo de las responsabilidades y del comportamiento del proxy, tendremos varios tipos que realizarán unos tipos de tarea u otras. Los proxies más comunes son los siguientes:

• Proxy remoto: un proxy remoto se comporta como un representante local de un objeto remoto. Se encarga principalmente de abstraer la comunicación entre nuestro cliente y el objeto remoto. Es el embajador de los proxies.
• Proxy virtual: se encarga de instanciar objetos cuyo coste computacional es elevado. Es capaz de sustituir al objeto real durante el tiempo que el verdadero objeto está siendo construido y proporcionar funcionalidades como el lazy loading (realizar operaciones computacionalmente costosas únicamente cuando el acceso a el elemento es requerido).
• Proxy de protección: establece controles de acceso a un objeto dependiendo de permisos o reglas de autorización.

Estructura del patrón

Si echamos un vistazo al diagrama, vemos que la estructura de este patrón es bastante sencilla:

• Tenemos una clase abstracta (o interfaz) Elemento que define las operaciones que deberá cumplimentar tanto nuestro objeto real (ElementoReal) como el proxy que actuará de intermediario (ElementoProxy). Ambos elementos, al heredar de Elemento, deberán ser, por tanto, intercambiables. De este modo, sustituir un objeto de la clase ElementoReal por un ElementoProxy debería de ser -idealmente- transparente.
• La clase ElementoReal es aquella que contiene la verdadera funcionalidad, es decir, la clase que se quiere «proteger» a través del proxy. En el ejemplo de los navegadores, se correspondería al ordenador que realiza la petición HTTP. Este elemento tendrá un conjunto de operaciones, heredadadas desde Elemento. Usando el símil de los ordenadores, una operación podría ser HttpGet o HttpPost.
• La clase ElementoProxy también hereda de Elemento, y como tal, posee todos sus métodos. La diferencia fundamental es que también incorpora una referencia a otro Elemento. Así, tal y como ocurría en otros patrones como Adapter o Decorator, el método codificado dentro de esta clase realizará ciertas operaciones de control y/o transformación para posteriormente invocar el método original del ElementoReal que tiene referenciado. Por ejemplo, si nuestro proxy no quisiera permitir las conexiones a una página en concreto, su comportamiento sería algo similar al siguiente:

    private class ElementoProxy : Elemento
    {
        // Incluímos una referencia a otro elemento.
        private Elemento elemento;

        // Inyectamos el elemento a través del constructor.
        public ElementoProxy(Elemento elemento)
        {
            this.elemento = elemento;
        }

        // El método HttpGet realizará comprobaciones y/o adaptaciones para
        // posteriormente realizar la llamada al método homónimo del objeto real
        public string HttpGet(string uri)
        {
            if (uri.ToLower().Contains("paginaprohibida.com"))
                return null;
            else
                return HttpGet(uri);
        }
    };

 

A estas alturas, si habéis echado un ojo a los patrones anteriores, este concepto os resultará pan comido. El patrón Proxy realiza una tarea similar a la que realizaba el patrón Adapter, salvo que en lugar de transformar la interfaz del objeto (ambos objetos heredan de la misma clase y, por tanto, comparten interfaz), éste utilizará la misma, pero realizando una serie de operaciones adicionales antes (o después) de realizar la llamada al método de la clase original.

Es más, el concepto de añadir funcionalidad a una clase que puede hacerse pasar por otra añadiendo nueva funcionalidad inyectando el objeto original a través del constructor es un concepto que también hemos visto antes en el patrón Decorator. El patrón Proxy es muy similar a éste último, con la diferencia (nuevamente) de su objetivo: mientras que el patrón Decorator añade nuevas responsabilidades a un objeto de forma dinámica, el patrón Proxy únicamente realiza operaciones de control de acceso sobre ese objeto. De hecho, el Proxy tiene una capacidad que no tiene el Decorator: tiene la capacidad de instanciar objetos de la clase que encapsula. En el ejemplo aquí mostrado el objeto es inyectado, pero en determinados casos, este podría ser perfectamente instanciado. Esto suele ser común en el llamado Virtual Proxy, en el que el Proxy puede proporcionar un comportamiento «por defecto» mientras realiza la operación que requiera cierto coste computacional.

Por lo tanto, nos encontramos una colección de cosas que ya nos son familiares: una clase abstracta de la que heredan ambos elementos, inyectar un objeto en otro a través de su constructor, realizar una composición de objetos al añadir una referencia del objeto original dentro del objeto de la clase proxy… Como vemos, los mismos conceptos se repiten una y otra vez. Una vez comprendidos, la comprensión de los patrones se simplifica muchísimo.

Otra posible versión de este patrón resultaría en realizar la herencia de forma lineal, es decir, haciendo que el proxy herede del elemento real y sobrecargando los métodos que requieran supervisión.

Con este modelo evitaremos que nuestro proxy tenga que incluir una referencia al objeto real, ya que podemos realizar la misma operación sobrecargando el método y llamando al método de la clase base en lugar de invocar el método del objeto inyectado a través del constructor. Usando esta estructura podríamos incluso evitar que ElementoReal herede de una clase abstracta o implemente una interfaz, simplificando el código… pero forzando a nuestro diseño que dependa de una concreción en lugar de depender de una abstracción. En la medida de la posible, intentaremos respetar este principio.

Arrancando el vehículo

Atrás quedaron los días en que el sistema de arranque de nuestro vehículo consistía en una llave dentada que encajaba con los pernos de la cerradura. La electrónica y la informática hace tiempo que ha llegado a la automoción, y por ello la nueva serie de vehículos Dorfwagen incorpora una centralita con un complejo sistema de seguridad que es capaz de comprobar si el código de la llave coincide con el de la centralita. En los modelos de gama alta, además de realizar esta operación estándar, la centralita proporciona un sistema de seguridad capaz de detectar si la llave ha sido falsificada.

Nuestra centralita, por tanto, proporciona dos atributos: uno que se corresponderá con el código de la llave y otro que identificará al código de seguridad.

    public class CentralitaVehiculo
    {
        private int codigoLlave;
        private int codigoSeguridad;

        public CentralitaVehiculo(int codigoLlave, int codigoSeguridad)
        {
            this.codigoLlave = codigoLlave;
            this.codigoSeguridad = codigoSeguridad;
        }

        public int CodigoLlave {
            get { return codigoLlave; }
        }
        public int CodigoSeguridad {
            get { return codigoSeguridad; }
        }
    }

Dado que disponemos de dos gamas (alta y baja), necesitaremos implementar, partiendo de la misma centralita, un sistema que sea compatible con ambos pero que sea capaz de realizar una comprobación adicional si la llave del vehículo es de gama alta. Comenzaremos codificando la clase abstracta Llave de la cual heredará tanto la funcionalidad base de nuestra llave LlaveReal como la clase que hará de veces de proxy, LlaveProxy.

    // Clase abstracta de la que heredará el elemento original y el proxy
    public abstract class Llave
    {
        // Código de la llave
        protected int codigoLlave;

        // Propiedad de sólo lectura para obtener el código de la llave
        public int CodigoLlave
        {
            get { return codigoLlave; }
        }

        // Métodos abstractos que implementarán el elemento real y el proxy
        public abstract void RealizarContacto(CentralitaVehiculo centralita);
        public abstract bool LlaveCorrecta(int codigoLlave);
    }

Esta llave contiene un atributo que almacenará el código de la llave, más dos métodos que deberán ser implementados por las clases hija: RealizarContacto, que arrancará el vehículo, y LlaveCorrecta, que será invocada por el método anterior y comprobará si el código de la centralita y de la llave coinciden.

Nuestra clase LlaveReal, por tanto, mostrará el comportamiento básico que se espera de ella: comprobará que llave y centralita comparten código y realizará el arranque del vehículo en caso de que así sea.

    public class LlaveReal : Llave
    {
        // Constructor base: asigna el código de la llave a la llave
        public LlaveReal(int codigoLlave)
        {
            this.codigoLlave = codigoLlave;
        }

        // Realizar contacto: comprueba que el código de la llave sea correcto.
        // En caso de que lo sea, arranca el vehículo.
        public override void RealizarContacto(CentralitaVehiculo centralita)
        {
            if (LlaveCorrecta(centralita.CodigoLlave))
                Console.WriteLine("Contacto realizado");
            else
                Console.WriteLine("Código de llave inválido");
        }

        // Comprueba que el código proporcionado coincide con el de la llave
        public override bool LlaveCorrecta(int codigoLlave)
        {
            return codigoLlave == this.codigoLlave;
        }
    }

Hasta aquí, nada que se separe de un diseño convencional. Es hora de implementar nuestro proxy, que también hereda de Llave. La diferencia fundamental con la clase anterior radica en que:

• Su constructor acepta un objeto de la clase Llave, que será inyectado para ser invocado en los métodos LlaveCorrecta y RealizarContacto.
• Debido a lo anterior, nuestra clase deberá incluir una referencia a Llave.
• El método LlaveCorrecta se limitará a invocar el método LlaveCorrecta de la llave que se ha inyectado a través del constructor.
• Finalmente, el método RealizarContacto será el encargado de realizar la comprobación adicional: antes de comparar los códigos de la llave y de la centralita invocando a LlaveCorrecta realizará una comprobación previa, utilizando algún tipo de algoritmo para asegurarse de que el código de seguridad de la centralita permite el código de la llave insertada. En caso de que sea correcto, el control de acceso habrá sido superado y se ejecutará el código correspondiente a LlaveReal. En caso contrario, se denegará el arranque:

    public class LlaveProxy : Llave
    {
        // Referencia a la llave original
        private Llave llaveOriginal;

        // Constructor en el que se inyectará el objeto real
        public LlaveProxy(Llave llave)
        {
            llaveOriginal = llave;
        }

        // Este método realizará el control de acceso sobre el método original.
        // Realizará una comprobación previa comparando el código de seguridad y, si este es
        // correcto, invocará el método del objeto real.
        public override void RealizarContacto(CentralitaVehiculo centralita)
        {
            // Realizamos una comprobación adicional de seguridad. En caso de no cumplirse, se
            // aborta la operación. Esta operación podría ser la ejecución de un algoritmo para
            // comprobar la autenticidad del código de la llave, una comprobación de nombre de
            // usuario y contraseña... o cualquier otra comprobación que queramos realizar.
            if (centralita.CodigoSeguridad > llaveOriginal.CodigoLlave.ToString().GetHashCode())
            {
                Console.WriteLine("Código de seguridad incorrecto. Abortanto arranque");
                return;
            }

            if (LlaveCorrecta(centralita.CodigoLlave))
                Console.WriteLine("Contacto realizado");
            else
                Console.WriteLine("Código de llave inválido");
        }

        // Este método no realizará comprobaciones adicionales. Se limitará a invocar el método
        // del objeto real.
        public override bool LlaveCorrecta(int codigoLlave)
        {
            return llaveOriginal.LlaveCorrecta(codigoLlave);
        }
    }

La llave simple realizará un arranque normal y correcto siempre que el código de centralita y de la llave coincidan. No obstante, en los vehículos de gama alta, si utilizamos un código de seguridad erróneo, el motor no arrancará:

            int codigoLlave = 532543463;
            int codigoSeguridad = 1038948470;

            CentralitaVehiculo centralita = new CentralitaVehiculo(codigoLlave, codigoSeguridad);

            Llave llaveSimple = new LlaveReal(codigoLlave);
            llaveSimple.RealizarContacto(centralita);

            Llave proxy = new LlaveProxy(llaveSimple);
            proxy.RealizarContacto(centralita);

Por el contrario, si el código es válido, se procederá al arranque de forma normal.

            int codigoLlave = 532543463;
            int codigoSeguridad = -1098948470;

            CentralitaVehiculo centralita = new CentralitaVehiculo(codigoLlave, codigoSeguridad);

            Llave llaveSimple = new LlaveReal(codigoLlave);
            llaveSimple.RealizarContacto(centralita);

            Llave proxy = new LlaveProxy(llaveSimple);
            proxy.RealizarContacto(centralita);

Como podemos observar, ambos objetos pueden ser intercambiados, ya que al utilizarse una clase común (Llave), lo único que deberá hacer el cliente es invocar el método necesario para realizar el arranque (RealizarContacto). El código implementado por cada clase queda fuera del alcance del cliente, que lo único que espera es que el vehículo arranque o muestre un mensaje de error.

¿Cuándo utilizar este patrón? Ejemplos reales

Este patrón es aconsejable en los siguientes supuestos:

• Retrasar una invocación a una petición con alto coste computacional hasta que sea necesario (lazy loading). Un ejemplo de este comportamiento sería, por ejemplo, cumplimentar un diccionario interno que requiera realizar varias conexiones a base de datos únicamente cuando se solicite información de uno de los elementos contenidos en el diccionario.
• Simplificar la interacción con elementos remotos: si el objeto es local, las invocaciones serán las habituales. Si el objeto es remoto, el proxy implementará los mecanismos de comunicación haciéndolos transparentes al cliente.

Ejemplos de este patrón pueden ser la tecnología RMI de Java, en el que la invocación de un objeto remoto se realiza a través de un Stub. Este Stub no es más que una clase que expone las mismas operaciones que el objeto remoto, pero que hace que la petición sea transparente para el cliente, realizando de forma interna las operaciones de comunicación.

Otro ejemplo serían las pantallas de carga de ciertas aplicaciones. En este caso, se tratará de un Proxy Virtual, que mostrará el típico mensaje de «Cargando» mientras recupera la información solicitada por el usuario, sobreescribiendo el mensaje una vez que la petición al objeto real ha concluido.

Fuentes:

• Head First Design Patterns (Freeman et al.)
• Pluralsight – Design Patterns Library: Proxy Pattern (Steve Smith)
• OODesign: Proxy Pattern (OODesign.com)

«Componer objetos en árboles para representar jerarquías todo-parte. Composite permite a los clientes tratar objetos individuales y objetos compuestos de una manera uniforme».

Design Patterns: Elements of Reusable Object-Oriented Software

El patrón Composite se aleja un poco de la línea tradicional de los patrones vistos hasta ahora, ya que rompe uno de los principios de la programación orientada a objetos: una clase, una responsabilidad. En realidad, los más puristas pueden decidir no hacerlo, pero el precio a pagar es demasiado alto para los ingenieros mortales: la simplicidad del modelo.

Cuando diseñamos debemos tener claro que la idea principal es alcanzar un equilibrio entre muchos factores como por ejemplo presupuesto, usabilidad y facilidad para que nuestro código sea reutilizable y pueda ser fácilmente mantenible en un futuro. Si el objetivo del anterior patrón, Flyweight, era el rendimiento, el sine qua non de este patrón es la facilidad de uso.

A grandes rasgos, el patrón Composite permite crear una jerarquía de elementos anidados unos dentro de otros. Cada elemento permitirá alojar una colección de elementos del mismo tipo, hasta llegar a los elementos «reales» que se corresponderán con los nodos «Hoja» del árbol. Un ejemplo del concepto de la jerarquía que se pretende modelar sería el de los menús de una aplicación:

En este ejemplo tenemos un menú (Archivo) que contiene varios elementos, que pueden ser «hojas» que ejecutan una operación (Abrir, CreatePDF en línea.., Compartir archivos usando SendNow Online…, Adjuntar a correo electrónico…) o bien otro menú (Guardar como) que a su vez contiene más elementos «hoja» (PDF…, Texto…, Word o Excel Online…).

Creo que el ejemplo es lo suficientemente ilustrativo como para entender el concepto: poder anidar menús que puedan contener o bien otros menús, o bien directamente nodos hoja que ejecuten operaciones. Este ejemplo se aproxima bastante al concepto de Composite, pero no se ajusta exactamente a su filosofía, ya que le falta una funcionalidad: el submenú debería ser capaz de ejecutar una operación que se encargaría de iterar sobre todos los subelementos que contiene, ejecutando la operación de cada uno de ellos. Sin embargo, deja bastante claro el esquema lógico que seguirá este patrón.

Llevando el coche al taller

Para ilustrar el patrón, acudiremos a un taller, que tuvo a bien contratar a un ingeniero de software para que le diseñara una aplicación para realizar el inventariado de las piezas de recambio. El dueño del taller le expuso al ingeniero la dificultad que tenía para establecer los precios de los recambios, ya que dependiendo de la avería, a veces era necesario cambiar piezas enteras mientras que en otras ocasiones bastaba con sustituir un pequeño componente. Nuestro cliente había almacenado en una base de datos cada uno de los componentes con su respectivo precio, pero cuando el proveedor le aumentaba el precio de una pieza que formaba parte de otra, tenía que preocuparse de actualizar, una a una, todas las piezas de grano más grueso en las cuales estaba contenida esta pieza. Por poner un ejemplo, si el precio de un tornillo para una rueda aumentaba, nuestro mecánico tenía que acceder a su catálogo y modificar el precio total en:

• Tornillo para rueda
• Llantas (en todos y cada uno de los modelos que usaran los tornillos anteriores)
• Ruedas (en todos y cada uno de los modelos que usaran las llantas anteriores)

Como podemos imaginar, esta situación era muy laboriosa. Así pues, nuestro ingeniero desarrolló un sistema que realizara el cálculo del precio de forma automática a la vez que modelaba el almacén de recambios con una estructura arborescente. En lugar de disponer del siguiente modelo:

Le proporcionamos este:

Aplicando Composite

Es hora de ensuciarnos un poco las manos y plantar cara a nuestro código. Comenzaremos creando nuestro elemento abstracto o interfaz correspondiente al «Componente». Esta clase o interfaz debe exponer los métodos comunes tanto a los elementos compuestos como a los elementos «hoja». Lo verdaderamente importante es que este elemento sea una abstracción (depender de abstracciones, no de concreciones).

• Si optamos por la interfaz, simplemente definiremos sus operaciones.
• Si optamos por la clase abstracta, además de definir sus operaciones, añadiremos un comportamiento por defecto en el que lanzaremos una excepción que indique que la operación no está soportada. De este modo, las clases derivadas deberán encargarse de proporcionar la funcionalidad. En caso de no proporcionarla, lanzarán una excepción (por ejemplo, el método add en un elemento Hoja no tiene sentido, por lo que deberá tener este comportamiento por defecto).

Nuestra clase Componente será, por tanto, el siguiente:

    public abstract class ComponenteRecambio
    {
        #region Métodos comunes a objetos compuestos y hojas

        public virtual string getNombre()
        {
            throw new NotSupportedException(this.GetType().Name + "getNombre()");
        }

        public virtual void setNombre(string nombre)
        {
            throw new NotSupportedException(this.GetType().Name + "setNombre()");
        }

        public virtual string getDescripcion()
        {
            throw new NotSupportedException(this.GetType().Name + "getDescripcion()");
        }

        public virtual void setDescripcion(string descripcion)
        {
            throw new NotSupportedException(this.GetType().Name + "setDescripcion()");
        }

        public virtual double getPrecio()
        {
            throw new NotSupportedException(this.GetType().Name + "getPrecio()");
        }

        public virtual void setPrecio(double precio)
        {
            throw new NotSupportedException(this.GetType().Name + "setPrecio()");
        }

        #endregion

        #region Métodos exclusivos de los objetos compuestos

        public virtual void add(ComponenteRecambio componente)
        {
            throw new NotSupportedException(this.GetType().Name + "add()");
        }

        public virtual void remove(ComponenteRecambio componente)
        {
            throw new NotSupportedException(this.GetType().Name + "remove()");
        }

        public virtual ComponenteRecambio getElemento(int indice)
        {
            throw new NotSupportedException(this.GetType().Name + "getElemento()");
        }

        #endregion
    }

Sobre esta clase trabajaremos creando otras dos clases que simbolizarán los dos tipos de elemento que puede contener nuestro patrón Composite: elementos hoja (ElementoRecambio) y elementos compuestos (Recambio). Así, nuestros elementos «hoja» serán los que incorporen la verdadera funcionalidad, que será invocada por los elementos compuestos en caso de que fuera necesario.

Hemos utilizado «nomenclatura Java» (getters y setters en lugar de una propiedad para ambas operaciones) porque a la hora de sobrecargar los métodos será más intuitivo si las operaciones se encuentran separadas, como veremos más adelante. Por supuesto, para quien lo desee, también es posible usar propiedades virtuales y sobrecargarlas del mismo modo que hacemos con estos dos métodos.

Volviendo a nuestro código, nuestra clase ElementoRecambio almacenará información como el nombre, la descripción y el precio:

    public class ElementoRecambio : ComponenteRecambio
    {
        // Atributos propios del nodo hoja.
        private string nombre;
        private string descripcion;
        private double precio;

        // Constructor
        public ElementoRecambio(string nombre, string descripcion, double precio)
        {
            this.nombre = nombre;
            this.descripcion = descripcion;
            this.precio = precio;
        }

        // Sobrecargamos únicamente los métodos propios de los nodos hoja, destinados
        // a devolver la información y a asignarla

        // NOMBRE
        public override string getNombre()
        {
            return nombre;
        }

        public override void setNombre(string nombre)
        {
            this.nombre = nombre;
        }

        // DESCRIPCION
        public override string getDescripcion()
        {
            return descripcion;
        }

        public override void setDescripcion(string descripcion)
        {
            this.descripcion = descripcion;
        }

        // PRECIO
        public override double getPrecio()
        {
            return precio;
        }

        public override void setPrecio(double precio)
        {
            this.precio = precio;
        }

        // Los métodos add, remove y getElemento no se sobrecargarán, ya que
        // el nodo hoja no estará compuesto por más elementos que él mismo.
        // Por tanto, si se invocan estos métodos, se llamará el método padre
        // que lanzará una excepción de tipo NotSupportedException
    }

Seguramente, a estas alturas ya nos habremos dado cuenta de lo que comentábamos al principio del artículo respecto a la ruptura del principio de responsabilidad única. La clase Elemento implementa un conjunto de métodos, pero deja otro conjunto sin implementar (los métodos add, remove y getElemento), que lanzarán una excepción si te utilizan. Esos métodos serán implementados por la siguiente clase: Recambio.

    public class Recambio : ComponenteRecambio
    {
        // Arraylist que contendrá los elementos hijo
        private ArrayList listaRecambios;

        // Atributos
        private string nombre;
        private string descripcion;

        // Constructor que recibirá el nombre, el precio y la descripción.
        public Recambio(string nombre, string descripcion, double precio)
        {
            // Instanciamos el ArrayList
            listaRecambios = new ArrayList();

            // Asignamos el nombre, la descripción y el precio
            this.nombre = nombre;
            this.descripcion = descripcion;
            this.precio = precio;

        }

        #region Métodos relacionados con el árbol

        // Añade un nuevo elemento al ArrayList
        public override void add(ComponenteRecambio componente)
        {
            listaRecambios.Add(componente);
        }

        // Elimina un elemento del ArrayList
        public override void remove(ComponenteRecambio componente)
        {
            listaRecambios.Remove(componente);
        }

        // Recupera un elemento del ArrayList
        public override ComponenteRecambio getElemento(int indice)
        {
            return (ComponenteRecambio)listaRecambios[indice];
        }

        #endregion

    } 

En esta primera etapa, hemos codificado la parte que se encarga de añadir, eliminar y consultar otros elementos. El método es sencillo: a través de un ArrayList interno, los métodos add, remove y getElemento realizarán operaciones sobre él.

A continuación codificaremos los métodos get que recuperarán el contenido de los atributos de cada ElementoRecambio: nombre, descripción y precio. Para ello iteraremos sobre los elementos contenidos dentro de cada Recambio.

El precio, sin ir más lejos, se calculará a partir de los precios de los elementos contenidos en cada ElementoRecambio, que se sumará al precio del propio componente.

        #region Métodos relacionados con el elemento

        public override string getNombre()
        {
            string nombreCompleto = this.nombre + "\n";

            foreach(ComponenteRecambio c in listaRecambios)
                nombreCompleto += c.getNombre();

            return nombreCompleto;
        }

        public override string getDescripcion()
        {
            string descripcionCompleta = this.descripcion + "\n";

            foreach (ComponenteRecambio c in listaRecambios)
                descripcionCompleta += c.getDescripcion();

            return descripcionCompleta;
        }

        public override double getPrecio()
        {
            double precioTotal = this.precio;

            foreach (ComponenteRecambio c in listaRecambios)
                precioTotal += c.getPrecio();

            return precioTotal;
        }

        #endregion

También sobrecargaremos los métodos setNombre, setDescripcion y setPrecio.

        public override void setNombre(string nombre)
        {
            this.nombre = nombre;
        }

        public override void setDescripcion(string descripcion)
        {
            this.descripcion = descripcion;
        }
        public override void setPrecio(double precio)
        {
            this.precio = precio;
        }

Recorriendo todos los elementos contenidos dentro de cada recambio podremos obtener la información almacenada tanto en un objeto nodo (Recambio) como en un objeto hoja (ElementoRecambio). Ambos se tratarán de la misma manera, aunque la implementación de los métodos sea distinta. Y dado que ambos objetos son intercambiables, estamos consiguiendo lo que declaramos en primera instancia: componer objetos de forma arborescente respetando la jerarquía todo-parte permitiendo que ambos elementos se traten de forma uniforme.

            // Declaramos los tornillos incluidos en la llanta, que serán nodos hoja
            ComponenteRecambio tornillo1 = new ElementoRecambio("Tornillo llanta", "Tornillo llanta marca ACME", 0.21);
            ComponenteRecambio tornillo2 = new ElementoRecambio("Tornillo llanta", "Tornillo llanta marca ACME", 0.21);
            ComponenteRecambio tornillo3 = new ElementoRecambio("Tornillo llanta", "Tornillo llanta marca ACME", 0.21);
            ComponenteRecambio tornillo4 = new ElementoRecambio("Tornillo llanta", "Tornillo llanta marca ACME", 0.21);

            // Declaramos la llanta, que poseerá cuatro tornillos. Por tanto, se tratará de un elemento Composite (compuesto
            // por otros elementos, que pueden ser compuestos u hojas)
            ComponenteRecambio llanta = new Recambio("Llanta ACME 15'", "Llanta ACME de 15'", 42.22);

            // Añadimos los tornillos a la llanta
            llanta.add(tornillo1);
            llanta.add(tornillo2);
            llanta.add(tornillo3);
            llanta.add(tornillo4);

            // Declaramos ahora otro elemento: la válvula de la rueda
            ComponenteRecambio valvula = new ElementoRecambio("Válvula", "Válvula de neumático genérica", 0.49);

            // Realizamos lo mismo con el neumático
            ComponenteRecambio neumatico = new ElementoRecambio("Neumático 15'", "Neumático Michelin de 15'", 13.42);

            // Declaramos un nuevo objeto compuesto: la rueda.
            // Este objeto estará compuesto por la llanta, la válvula y el neumático.
            // A su vez, la llanta incluirá los tornillos.
            // Establecemos el precio de la rueda a '0', ya que dependerá en exclusiva del contenido de sus elementos.
            ComponenteRecambio rueda = new Recambio("Rueda 15'", "Rueda de 15' con llanta ACME y neumático Michelin", 0);

            // Añadimos a la rueda los elementos hoja que instanciamos previamente
            rueda.add(llanta);
            rueda.add(neumatico);
            rueda.add(valvula);

Si consultamos el método getNombre() de nuestra rueda, se mostrará el contenido del atributo privado nombre para, a continuación, iterar sobre cada elemento del ArrayList invocando a su vez el método getNombre() de cada elemento de forma recursiva. Así, obtendríamos lo siguiente:

            Console.WriteLine(rueda.getNombre());

Lo cual nos daría la siguiente salida:

Si hacemos lo propio con el precio, obtendríamos la suma de todos los precios de sus elementos hoja. Si después de esto realizamos una modificación en el precio de uno de los elementos contenidos dentro del objeto compuesto, el cambio se propagará de forma automática sin necesidad de modificar el precio total de cada rueda.

            double precioTotal = rueda.getPrecio();

            Console.WriteLine("El precio total de la rueda es " + precioTotal);

            // Modificamos el precio de los tornillos para ver cómo afecta al precio total
            tornillo1.setPrecio(0.34);
            tornillo2.setPrecio(0.34);
            tornillo3.setPrecio(0.34);
            tornillo4.setPrecio(0.34);

            precioTotal = rueda.getPrecio();
            Console.WriteLine("El precio total de la rueda tras la subida de precio es " + precioTotal);

Esto producirá la siguiente salida:

Purismo vs. Transparencia

Nos acabamos de encontrar con el primer patrón que viola deliberadamente uno de los principios de la programación orientada a objetos. El motivo ha sido que el incremento en la transparencia (y usabilidad) es tan importante que merece la pena el sacrificio de permitir que una clase adquiera más de una responsabilidad. Recordemos que los patrones de diseño son soluciones genéricas a problemas concretos, por lo que su objetivo es la de facilitar el desarrollo de software. Hay ocasiones, por tanto, en las que las que las ventajas de romper las normas sobrepasan de largo seguirlas a rajatabla.

¿Cuándo utilizar este patrón? Ejemplos reales

Los escenarios en los que este patrón suele utilizarse son, principalmente:

• Como su propia definición indica, cuando se requiere representar jerarquías todo-parte que superen cierto tamaño.
• Cuando se desea que los clientes puedan ignorar la diferencia entre colecciones de objetos y objetos individuales, haciendo que ambos se traten de la misma manera.

El ejemplo más sencillo de visualizar de este patrón son los controles de un formulario, por ejemplo de WinForms. Los objetos (botones, literales, paneles…) heredan de la clase Control, que, de base, puede contener a su vez una colección de otros objetos que hereden de la clase Control. Cada uno de estos controles pueden tratarse bien como un control individual en sí o como una colección de controles (un panel puede contener, por poner un ejemplo, un Label, un Button y un RadioButton).

El sistema del pipeline de petición/respuesta de ASP.NET también sigue este esquema.

Finalmente, la estructura de ficheros y directorios de un sistema de archivos también actúa en consonancia con este patrón.

Fuentes:

• Head First Design Patterns (Freeman et al.)
• Composite (doFactory)