Nuevos Programadores

El patrón decorador, (decorator pattern), añade nuevas responsabilidades a un objeto dinamicamente, ofreciendo una alternativa flexible a la herencia.

En otras palabras, es una forma de agregar funcionalidades a una clase, extendiéndola pero sin recurrir a la herencia. ¿Por qué no heredar? Bueno, tal vez no desees dar acceso a toda la clase primaria y entonces sólo se daría acceso a lo necesario.

Veamos un ejemplo simple, tenemos las siguientes clases:

• Persona (ID, Nombre, Apellido y Fecha de Nacimiento)
• Usuario (ID, Nombre, Apellido, Usuario, Passwd)
• Cliente (ID, Nombre, Apellido, Teléfono, Email)
• Cliente VIP (ID, Nombre, Apellido, Teléfono, Email, Nro de Cuenta, Límite de Crédito)

Cómo vemos todos tienen campos comunes a Persona, pero no tienen todos los campos de la clase Persona, por eso no podemos heredar, así es que podremos implementar decoradores para la clase Persona, tendremos los decoradores Usuario, Cliente y Cliente VIP. (Ver figura 1).

Pero si analizamos lo que hemos diseñado hasta el momento podremos observar que Cliente VIP podría llegar a convertirse en un decorador de Cliente, que como recordamos es un decorador de Persona, de esa manera no tendremos que reescribir la lógica detrás de los atributos Teléfono e Email. (Ver figura 2).

La pregunta es cómo decorar una clase, pues a grandes rasgos podríamos decir que se trata de tener una variable privada de la clase a decorar, escribir los métodos o atributos que se deseen publicar de la clase a decorar y luego agregar las decoraciones en nuestra nueva clase, entendiendo por decoraciones los nuevos métodos y/o atributos.

Por último veamos el código correspondiente a nuestras clases.

class Persona
{
	private int ID;
	private String Nombre;
	private String Apellido;
	private Date FechaNac;
 
	public int getID()
	{
		return ID;
	}
 
	public String getNombre()
	{
		return Nombre;
	}
 
	public String getApellido()
	{
		return Apellido;
	}
 
	public Date getFechaNac()
	{
		return FechaNac;
	}
}
 
class Usuario
{
	private Persona mPersona;
 
	private String Usuario;
	private String Passwd;
 
	public int getID()
	{
		return mPersona.getID();
	}
 
	public String getNombre()
	{
		return mPersona.getNombre();
	}
 
	public String getApellido()
	{
		return mPersona.getApellido();
	}
 
	public String getUsuario()
	{
		return Usuario;
	}
 
	public String getPasswd()
	{
		return Passwd;
	}
}
 
class Cliente
{
	private Persona mPersona;
 
	private String Telefono;
	private String Email;
 
	public int getID()
	{
		return mPersona.getID();
	}
 
	public String getNombre()
	{
		return mPersona.getNombre();
	}
 
	public String getApellido()
	{
		return mPersona.getApellido();
	}
 
	public String getTelefono()
	{
		return Telefono;
	}
 
	public String getEmail()
	{
		return Email;
	}
}
 
class Cliente_VIP
{
	private Cliente mCliente;
 
	private String NroCuenta;
	private Double LimiteCredito;
 
	public int getID()
	{
		return mCliente.getID();
	}
 
	public String getNombre()
	{
		return mCliente.getNombre();
	}
 
	public String getApellido()
	{
		return mCliente.getApellido();
	}
 
	public String getTelefono()
	{
		return mCliente.getTelefono();
	}
 
	public String getEmail()
	{
		return mCliente.getEmail();
	}
 
	public String getNroCuenta()
	{
		return NroCuenta;
	}
 
	public Double getLimiteCredito()
	{
		return LimiteCredito;
	}
}

}

El patrón observador define una relación de uno a muchos, en la que un objeto único, al que llamaremos observable deberá notificar cada vez que cambie de estado a muchos objetos, que llamaremos observadores.

El funcionamiento de este patrón de diseño puede compararse con el de una suscripción a una revista, ya que los observadores se suscriben y cada vez que la revista, (observable), se actualiza, la misma se envía a los observadores suscriptos.

La definición del patrón observador es la siguiente: define una dependencia entre objetos de uno a muchos, de manera tal que cuando un objeto cambia su estado, todos sus dependientes son notificados y actualizados automaticamente.

Para demostrar el uso de este patrón, se ha creado un ejemplo en el que tenemos un form principal que tiene 2 botones, uno para abrir múltiples instancias de observadores, que en nuestro caso serán forms que mostrarán un listado desde una fuente de datos, un archivo XML más concretamente; y otro botón para abrir nuestro simulador de edición, que no es más que un form que nos permitirá editar la fuente de datos y nos permitirá observar que cada vez que alteramos los datos nuestros observadores serán notificados y actualizados automáticamente.

Es importante destacar que para una correcta implementación del patrón se utilizan interfaces que definen el rol de una clase como Observable u Observador, con lo cual nos olvidamos, por ejemplo de cómo se comporta cada clase cuando es notificada de un cambio de estado.

Veamos el diagrama de clases y a continuación el enlace para descargar nuestra mini-aplicación que implementa el patrón observador en C#.

Ejemplo de Patrón Observador en C# (155.92 KB)

}

Me acaba de llegar el libro Head First Design Patterns, el segundo de la serie Head First de O’Reilly que tengo en mi poder, (el primero es Head First C#).

Vi este libro hace un tiempo y lo empecé a leer, después de leer el patrón estrategia, decidí que tenía que comprar este libro, por lo que de ahora en adelante postearé los conocimientos que vaya obteniendo acerca de Patrones de Diseño.

El libro trae ejemplos en Java, pero yo voy a intentar crear mis propios ejemplos y en más de un lenguaje!

}

El patrón Estrategia (Strategy) define una familia de algoritmos, los encapsula y hace intercambiables. Permitiendo a cada algoritmo variar independientemente de los clientes que lo utilizan.

Se utiliza para encapsular aquellas partes del código que varían, haciendo que éstas variaciones no afecten al resto del código, evitando así consecuencias inesperadas y brindando a nuestro código una mayor flexibilidad.

Para ilustrarnos con un ejemplo, supongamos que tenemos un grupo de terminales las cuales tienen su propio método de entrada y salida de datos, por ej. teclado, monitor, mouse, etc.
Supongamos que en éste momento sólo tenemos 3 métodos de entrada y 2 de salida, pero sabemos que en el futuro se van a agregar más, por ello recurriremos al Patrón Estrategia para encapsular los métodos de entrada y salida, permitiéndonos en el futuro implementar las nuevas terminales con gran facilidad y sin afectar a las ya existentes.

Para encapsular los métodos de entrada recurriremos al uso de interfaces, crearemos una interface Entrada y una Salida, las cuales serán implementadas por cada método de entrada/salida de datos. A su vez, necesitamos tener varias terminales y poder agregar los nuevos tipos, para ello utilizaremos herencia, todas nuestras terminales heredarán de la superclase Terminal.

La clase Terminal tendrá una variable de instancia del tipo Entrada (interface) y una del tipo Salida (interface).
Además crearemos una clase por cáda método de entrada y salida las cuales implementarán la interface correspondiente. También podremos definir una clase, por ejemplo Monitor_TouchScreen que implemente ambas interfaces, por lo que podremos utilizarlo como método de entrada y salida.

En los diagramas vemos las interfaces Entrada y Salida con las clases que la implementan, y la superclase Terminal con sus subclases.

Ahora podemos ir un paso más allá y crear una Terminal Mutable, (qué nombre, no?), por ese nombre me refiero a una Terminal que pueda cambiar sus método de entrada y/o salida en tiempo de ejecución, lo cual suena mucho más complejo de lo que realmente es, ya que la única diferencia con las terminales que hemos creado hasta el momento es que en esta tendremos que definirnos un setter para el método de entrada y uno para el método de salida, mientras que el resto no varía.

Luego de descargar esta implementación en Java hay que ir al directorio bin/ y ejecutar java TestTerminales

Ejemplo de Patrón Estrategia en Java (7.72 KB)

}

El patrón Singleton se utiliza cuando es necesario tener una única instancia de una clase para toda la aplicación, ésto se logra otorgando la responsabilidad de crear la instancia a la misma clase. En nuestro ejemplo vemos que el constructor es privado y la propiedad Instancia se encarga de instanciar el objeto, (si éste no fue instanciado antes), y devolver la única instancia.

El código de nuestra clase es el siguiente:

public class objetoSingleton 
{ 
	private DateTime _creacion; 
	private Int64 _contador = 0; 
 
	public event onCambioContador CambioContador; 
	public delegate void onCambioContador(Int64 nuevoValor); 
 
#region Singleton 
	private static Object lockObject = new Object();
	private static objetoSingleton _instancia; 
 
	private objetoSingleton() { 
		this._creacion = DateTime.Now; 
	} 
 
	public static objetoSingleton Instancia 
	{ 
		get 
		{ 
			lock (lockObject) 
			{ 
				if (_instancia == null) 
				{ 
					_instancia = new objetoSingleton(); 
				} 
				return _instancia; 
			} 
		} 
	} 
#endregion 
 
	public DateTime FechaHoraCreacion 
	{ 
		get { return _creacion; } 
	} 
 
	public void SumarContador(Int64 valor) 
	{ 
		_contador += valor; 
		CambioContador(_contador); 
	} 
 
	public Int64 Contador 
	{ 
		get { return _contador; } 
	} 
}

Como se puede ver en el código, al cambiar el valor del contador se lanza un evento, que luego capturaremos para mostrar el valor del contador.
Para probar nuestro Singleton, vamos a usar un form, que podrá acceder directamente al objeto para sumar 1 al contador, podrá además crear 42 hilos que sumarán números aleatorios al contador y también podrá crear instancias de si mismo.

Al final del artículo está el enlace para descargar el proyecto hecho en Visual Studio 2005, además en este post estudiaremos el manejo de hilos, (threads), en C# utilizado en el form.

Descargar el ejemplo de Patrón Singleton en C# (21.22 KB)

}