Utilización del patrón Observer en la V10

La comunicación es un problema cotidiano en programación, ya sea entre equipos técnicos o a la hora de notificar nuevos cambios a los clientes.

El Design Pattern Observer resuelve uno de estos problemas en la V10: cuando se produce un cambio en la propiedad de un objeto, todos los clientes interesados son informados y actualizados automáticamente.

Design Patterns

Los patrones de software, o patrones de diseño, son una forma organizada de crear aplicaciones reutilizables para los problemas recurrentes del día a día. En este sentido, los patrones de software son soluciones optimizadas y reutilizables a los problemas cotidianos de programación, lo que facilita el desarrollo de software con soluciones reutilizables. 

¿Es posible desarrollar software sin utilizar patrones de software? Sí. Sin embargo, si por un lado la aplicación cumple los requisitos funcionales para los que fue diseñada, lo que complace inmediatamente al Product Owner, por otro, cuando hablamos de una evolución de la solución que implica cambios, tiempo y costes, el sentimiento del Product Owner será diferente.

En estos escenarios, la evolución y el mantenimiento de la solución deben garantizarse invirtiendo en un buen diseño y en una arquitectura basada en estándares, interconectando en una primera fase a los arquitectos de software, a los responsables técnicos y, en última instancia, a todos los desarrolladores.

Aunque no existe un número definido y finito de patrones de software, lo cierto es que hay cientos de patrones y aún muchos por descubrir. En el famoso libro Design Patterns se presentan 23 patrones de software muy conocidos en este campo, divididos en varias categorías: patrones de creación, estructurales y de comportamiento.

En este artículo, exploraremos el patrón observer e instanciaremos su uso en un caso práctico con la versión 10, lo que nos permitirá resolver un problema real de los integradores.

Observer 

Este patrón, también conocido como Dependents, Publish-Subscribe, se aplica en situaciones en las que varios clientes necesitan ser notificados de nuevos cambios en el sistema. En la práctica, cuando se produce un cambio en la propiedad de un objeto, todos los clientes que han expresado su interés en ser notificados son informados y actualizados automáticamente.

El patrón observer presenta diversas variaciones. Sin embargo, existe un diseño básico que describe la necesidad de dos objetos: el subject (sujeto) y el observer (observador).

El observer es el objeto responsable de mostrar los datos, mientras que el subject representa una abstracción de negocio que se crea en función de los requisitos del sistema. Así, cuando se produce un cambio en el objeto "A", el observer recibe la actualización automática.

El caso V10 - Ejemplo

Como parte de una implementación, existe la necesidad de cambiar el valor de un campo de usuario cada vez que se identifica a un cliente concreto. Sin embargo, este campo está disponible tanto en la pestaña correspondiente como en un formulario y panel de contexto, y el cambio debe realizarse inmediatamente.

Clase responsable de la modificación del campo de usuario

public class UiEditorVendas : EditorVendas
{
	GestorCamposUtil getorCampos;

	public UiEditorVendas()
	{
		getorCampos = new GestorCamposUtil();

		Form1 f = new Form1(getorCampos);
		f.Show();
	}

	public override void ClienteIdentificado(string Cliente, ref bool Cancel, ExtensibilityEventArgs e)
	{
		var tab = CustomTabs.First(
			p => p is UserControl1 && 
				(p as UserControl1).Name == "UserControl1"
				) as UserControl1;

		tab.InicializaObserver(getorCampos);

		getorCampos.ValorCDUAlterado(13);
	}
}

Clase de la pestaña de usuario a la que se notificará el cambio de estado

public partial class UserControl1 : CustomTab, IObserver
{
	private ISujeito gestorCamposUtil;

	public UserControl1()
	{
		InitializeComponent();
	}

	public void InicializaObserver(ISujeito Campos)
	{
		this.gestorCamposUtil = Campos;
		gestorCamposUtil.registrarObservador(this);
	}

	public void atualizar(double Campo)
	{
		textBox1.Text = Campo.ToString();
	}
}

Conclusión

Aunque los patrones de software existen para simplificar los retos a los que se enfrentan los programadores, no siempre los vemos aplicados a las soluciones cotidianas. El caso presentado de la V10 demuestra que esta puede (y debe) ser la forma de resolver dificultades reales de forma sencilla y con un código fácil de mantener y evolucionar.