DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login

Padrão Observer

Veja neste artigo de Paulo Quicoli, como trabalhar com o padrão de projeto Observer.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo

 

Muitas vezes, nos mais diversos sistemas precisamos implementar algum comportamento que depende de um específico fator. Quando esse desenvolvimento é feito através de objetos desejamos que os objetos envolvidos estejam o mínimo possível interligados, aplicando a regra de “baixo acoplamento”, ou seja, quanto menos os objetos souberem um do outro, melhor.

Uma situação real

Temos um sistema de e-commerce que ao ser feita uma venda, o cliente que comprou o produto recebe um e-mail com uma confirmação, o setor de logística é notificado,  através do envio automatizado de um arquivo texto, do local de entrega do produto.

A maneira convencional

Como todo desenvolvedor RAD, de primeira mão já vemos tudo resumido em uma procedure que será disparada no evento onClick do botão “Confirmar Compra” gerando um algoritmo parecido com o da Listagem 1.

 

Listagem 1.  Algoritmo RAD do evento OnClick do botão “Confirmar Compra”

 

1 – Validar comprar

2 – Se a compra não é válida pára o processamento e notifica usuário

3 – Se for válida, notifica usuário e envia arquivo de texto

 

O principal problema que vejo nessa abordagem é de que um requisito da nossa regra de negócios está implementado na camada de apresentação do sistema. Qualquer mudança nessa área pode acarretar erros nas regras de negócio ou implicar em duplicação de código. Hoje nosso sistema é acessado através de uma página. E se amanhã tivermos que disponibilizar essa mesma rotina para algum parceiro que gostaria de integrar nossa rotina de vendas em seu sistema interno?  Eu faria isso através de web services, e quanto aquele código que fizemos no botão confirmar venda da página? Teríamos que replicá-lo no web service?

O desenvolvimento eficaz

Muitos desenvolvedores Delphi se prendem muito ao RAD, criando aplicações de maneira eficaz e não eficiente. Para entender melhor essa diferença vamos a um exemplo do cotidiano.

Eu possuo um aquário de quase 100 litros em casa, muito bonito. Minha esposa chega então, na hora do almoço, com um novo peixe.  Como é quase hora de sairmos para almoçar eu simplesmente pego o saco plástico com o peixe e o coloco boiando sobre a água do aquário, pra que a temperatura dos dois se iguale. Passado 10 minutos, retiro o peixe do saco plástico e o coloco no aquário.

Agi de forma eficaz, porque em 10 minutos transferi o peixe pro meu aquário sem estourar meu limite de tempo pro almoço e pensei no bem estar do peixe.

Agora vamos aos fatos. Não é apenas a diferença de temperatura da água que pode fazer mal ao peixe, mas também a diferença de PH, devemos fazer o peixe se habituar, de forma rápida, à nova água em que será introduzido.

A forma eficiente seria acrescentar à água que ele veio, em intervalos de 10 minutos, a água do meu aquário até que se triplique a quantidade de água. Ou seja, eu levaria no mínimo 20 minutos para fazer isso, mas teria a certeza do bem estar do novo peixe.

Voltando para a programação, a maneira eficiente seria isolar essas regras de negócio em classes de maneira tal que a camada de apresentação (web services, formulários desktop, páginas web, etc.) pudesse variar sem interferi-las.

Mas por falta de tempo, prática, ou até mesmo conhecimento, aplicamos a forma eficaz, que não está errada, mas deixa a desejar.

 

Sobre separar a camada de regras de negócio da camada visual, fica para um próximo artigo pois o assunto é muito extenso.

Mudança de pensamento

Quero apresentar hoje o padrão Observer. Ele é indicado para tratar situações de dependência como a mencionada no inicio do artigo. Sua utilização oferece o benefício de se relacionar duas ou mais classes sem criar um vínculo explícito entre elas.

Abaixo na Figura 1 temos a visão formal, um diagrama de classes UML, do padrão Observer.

 

 

Figura 1. Padrão Observer.

 

O padrão Observer abstrai a relação dos objetos definindo-os como Observer e Subject.

Observer são objetos que ficam aguardando por uma mudança no estado de determinado objetos para poderem tomar uma ação. Subject são os objetos que estão sendo observados.

Olhando para nossa situação, o objeto Venda é um Subject e a notificação ao usuário e envio de arquivo são os Observers.

Vamos colocar logo a mão na massa e implementá-lo para resolver nosso problema. Primeiramente vamos criar as duas classes base que representam o padrão em si, TSubject e TObserver, veja Listagem 2

 

Listagem 2. Classes TObserver e TSubject

  TObserver = class

  public

    FSubject: TSubject;

    procedure Update; virtual; abstract;

  end;

 

  TSubject = class

  public

    FObservers: TObjectList;

    procedure Attach(const Observer: TObserver);

    procedure Detach(const Observer: TObserver);

    procedure DetachAll;

    procedure Notify;

  end;

 

E na Listagem 3 vemos como implementar nosso Subject

 

Listagem 3. Implementação do Subject

procedure TSubject.Attach(const Observer: TObserver);

begin

  if FObservers = nil then

    FObservers := TObjectList.Create;

 

  Observer.FSubject := Self;

  fObservers.Add(Observer);

end;

 

 

procedure TSubject.Detach(const Observer: TObserver);

begin

  if fObservers <> nil then

  begin

    fObservers.Remove(Observer);

    if FObservers.Count = 0 then

      FObservers := nil;

  end;

end;

 

procedure TSubject.DetachAll;

var

  i, k: Integer;

begin

  if FObservers <> nil then begin

    k := FObservers.Count;

    for i := Pred(k) downto 0 do

      Detach(FObservers[i] as TObserver);

  end;

end;

 

procedure TSubject.Notify;

var

  i: Integer;

begin

  if FObservers <> nil then

    for i := 0 to FObservers.Count -1 do

      (fObservers[i] as TObserver).Update;

 

end;

 

Temos agora que implementar nossas classes de negócio que terão o comportamento do padrão observer, veja na listagem 4.

 

Listagem 4.  TObserver e TSubject implementados

  TVenda = class(TSubject)

  private

    FCliente: TCliente;

    FProduto: TProduto;

    FDataVenda: TDateTime;

    FQtdeVendida: integer;

    function GetConfirmacao: string;

    function GetDadosEntrega: string;

    procedure SetCliente(const Value: TCliente);

    procedure SetProduto(const Value: TProduto);

    procedure SetDataVenda(const Value: TDateTime);

    procedure SetQtdeVendida(const Value: integer);

  public

    constructor Create;

    destructor Destroy; override;

    property Cliente: TCliente read FCliente write SetCliente;

    property Produto: TProduto read FProduto write SetProduto;

    property DataVenda: TDateTime read FDataVenda write SetDataVenda;

    property QtdeVendida: integer read FQtdeVendida write SetQtdeVendida;

    procedure Finalizar;

  end;

 

  TLogistica = class(TObserver)

  public

    procedure Update; override;

  end;

 

  TConfirmacao = class(TObserver)

  public

    procedure Update; override;

  end;

 

O método Finalizar de TVenda, Listagem 5, chama o método herdado Notify que varre a lista de observers notificando a cada um que a compra foi finalizada.

 

Listagem 5. Método que chama o Notify

procedure TVenda.Finalizar;

begin

  {

   Aqui pode se validar a venda, e esta estando ok,

   notifica-se os observers, sejam quem forem

  }

  Notify;

end;

 

Posteriormente cada classe que implementa TObserver executa o método Update à sua maneira, conforme listagem 6.

 

Listagem 6. Método Update

{ TLogistica }

 

procedure TLogistica.Update;

begin

  if FSubject is TVenda then ShowMessage(TVenda(FSubject).GetDadosEntrega);

end;

 

{ TConfirmacao }

 

procedure TConfirmacao.Update;

begin

  if FSubject is TVenda then ShowMessage(TVenda(FSubject).GetConfirmacao);

end;           

 

Com essas classes implementadas, mais TCliente e TProduto, temos o que é chamado de Business Object Model, ou, Modelo de objetos de negócio. Nossas regras estão encapsuladas em classes, de tal forma que podemos variar a interface com o usuário.

Na Listagem 7 temos parte do código do exemplo que está anexado.

 

Listagem 7. Utilizando observer

procedure TForm1.FormCreate(Sender: TObject);

begin

{

  Preparando a venda...

 

  O preenchimento das classes FCliente e FProduto

  poderiam se dar de qualquer forma, como por um

  formulário comum, uma página Web ou até mesmo

  por um webservice

}

 

  FCliente := TCliente.Create;

  FCliente.Nome := 'Paulo Roberto Quicoli';

  FCliente.Endereco := 'Av. do Centro, S/N';

  FCliente.Email := 'pauloquicoli@gmail.com';

 

  FProduto := TProduto.Create;

  FProduto.Nome := 'TV de Plasma 42"';

  FProduto.Valor := 7899.00;

 

  FAvisaUsuario := TConfirmacao.Create;

  FAvisaLogistica := TLogistica.Create;

 

  FVenda := TVenda.Create;

{

  Veja que aqui adicionamos os observers

  que estão esperando pela conclusão da venda

}

  FVenda.Attach(FAvisaUsuario);

  FVenda.Attach(FAvisaLogistica);

end;

 

 

procedure TForm1.btFinalizarClick(Sender: TObject);

begin

{

  Aqui finalizamos a compra, mais uma vez digo

  que isso poderia se dar por um formulário comum,

  uma página web ou webservice

}

  FVenda.Cliente := FCliente;

  FVenda.Produto := FProduto;

  FVenda.DataVenda := now;

  FVenda.QtdeVendida := 1;

  FVenda.Finalizar;

end;

Conclusão

Encapsular nossas regras de negócio em classes é melhor coisa que podemos fazer para nossos projetos. Veja na Listagem 7, no código do evento btFinalizarClick não mencionamos a regra exigida, que era notificar usuário e enviar um arquivo para a logística. Tudo ficou no nosso modelo de negócios que, desenvolvido da forma sugerida, poderá ser reutilizado por outras interfaces.

A implementação do padrão Observer foi a mais simples possível, juntamente com o exemplo, para que a idéia do seu funcionamento pudesse ser assimilada de forma fácil.

Abraço e até mais!

 



Editor Geral da revista ClubeDelphi. Formado em processamento de dados pela FATEC-TQ. Atua como Analista de Sistemas na Siplan Control-M unidade Jaboticabal (www.siplancontrolm.com.br), prof. na FATEC-TQ e consultor na NHibernate [...]

O que você achou deste post?
Conhece a assinatura MVP?
Publicidade
Serviços

Mais posts