Utilização do Padrão Observer na V10

A Comunicação é um problema diário da programação, seja entre as equipas técnicas ou na notificação de novas alterações aos clientes.

O Design Pattern Observer vem resolver na V10 um destes problemas - quando existe uma alteração de uma propriedade de um objeto, todos os clientes interessados são informados e atualizados automaticamente.

Design Patterns

Os Padrões de Software, ou Design Patterns, são uma forma organizada de criar aplicações que sejam reutilizáveis para problemas recorrentes do dia a dia. Neste sentido, os padrões de software são soluções otimizadas e reutilizáveis para os problemas diários de programação, facilitando o desenvolvimento de software com soluções reutilizáveis. 

É possível desenvolver um software sem utilizar padrões de software? Sim! No entanto, se por um lado a aplicação responde aos requisitos funcionais para os quais foi desenhada que agradam de imediato ao Product Owner. Por outro lado, quando falarmos numa evolução da solução que implica alterações, tempo e custos, o sentimento do Product Owner já será outro.

Nestes cenários, a evolução e manutenção da solução devem ser garantidas através de um investimento num bom desenho e numa boa arquitetura baseada em padrões, interligando numa primeira fase os arquitetos de software, os Technical Lead e, no limite, todos os developers.

Apesar de não existir um número definido e finito de padrões de software, a verdade é que existem centenas de padrões e ainda muitos por descobrir. No famoso livro Design Patterns são apresentados 23 padrões de software conhecidos na área, divididos em várias categorias: padrões de criação, estruturais e comportamentais.

Neste artigo, vamos explorar o padrão observer e instanciar a sua utilização num caso prático com a versão 10, permitindo resolver um problema real dos integradores.

Observer 

Este padrão, também conhecido como Dependents, Publish-Subscribe, aplica-se nas situações onde vários clientes necessitam de ser notificados de novas alterações no sistema. Na prática, quando existe uma alteração de propriedade de um objeto, todos os clientes que manifestaram interesse em ser notificados são informados e atualizados automaticamente.

O padrão observer apresenta diversas variações. Contudo, existe um desenho base que descreve  a necessidade de dois objetos: o subject (sujeito) e o observer (observador).

O observer é o objeto responsável pela exibição de dados, enquanto que o subject representa uma abstração do negócio que é criado com base no requisito do sistema. Assim, quando ocorre uma alteração no objeto “A”, o observer recebe a atualização automática.

O Caso V10 - Exemplo

No âmbito de uma implementação, existe a necessidade de alterar o valor de um campo de utilizador sempre que um determinado cliente for identificado. No entanto, esse campo está disponível quer no respetivo separador, mas também num formulário e painel de contexto, devendo a alteração ser realizada imediatamente.

Classe responsável pela alteração do campo de utilizador

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);
	}
}

Classe do separador de utilizador que será notificado pela mudança 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();
	}
}

Conclusão

Embora os padrões de software existam com o propósito de simplificar os desafios colocados aos programadores, nem sempre assistimos à sua aplicação nas soluções do dia-a-dia. O caso apresentado da V10 demonstra que este pode (e deve) ser o caminho para resolver dificuldades reais de forma simples e  com código que é fácil manter e evoluir.