Design Patterns (Padrões de Projeto de Software) II: Observer
Continuando a série de artigos sobre Design Patterns, vamos discutir o Observer.
Vou novamente recorrer a definição da Wikipedia:
Define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seus dependentes sejam notificados e atualizados automaticamente. Isto é o padrão Observer e permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto.
O padrão Observer é também chamado de Publisher-Subscriber, Event Generator, Dependents.
O Observer é composto de duas partes, o Subject que é o objeto que muda de estado com uma frequência imprevisível e os Observers que devem pedir que sejam notificados das mudanças de estado do Subject.
Os Observers podem se "cadastrar" e "descadastrar" para receber essas notificações.
Veja um diagrama do pattern:
E vamos partir para os códigos:
ISubject.cs:
public interface ISubject
{
void Registrar(IObserver observador);
void Desregistrar(IObserver observador);
void Notificar();
}IObserver.cs:
public interface IObserver
{
void Atualizar();
}SubjectConcreto.cs:
private string _SubjectState = "ON";
public string SubjectState
{
get
{
return _SubjectState;
}
set
{
_SubjectState = value;
}
}
private List<IObserver> Observers = new List<IObserver>();
#region ISubject Members
public void Registrar(IObserver observador)
{
Observers.Add(observador);
}
public void Desregistrar(IObserver observador)
{
Observers.Remove(observador);
}
public void Notificar()
{
foreach (IObserver Observador in Observers)
{
Observador.Atualizar();
}
}
#endregion
}ObserverConcreto.cs:
public class ObserverConcreto : IObserver
{
private string _Nome;
private string _ObserverState;
private SubjectConcreto _Subject;
public SubjectConcreto Subject
{
get { return _Subject; }
set { _Subject = value; }
}
public ObserverConcreto(SubjectConcreto pSubject, string pNome)
{
this._Subject = pSubject;
this._Nome = pNome;
}
#region IObserver Members
public void Atualizar()
{
_ObserverState = _Subject.SubjectState;
Console.WriteLine("Novo estado do Observer {0} é {1}", _Nome, _ObserverState);
}
#endregion
}Agora que temos nossas classes, vamos testa-las:
static void Main(string[] args)
{
SubjectConcreto s = new SubjectConcreto();
s.Registrar(new ObserverConcreto(s, "X"));
s.Registrar(new ObserverConcreto(s, "Y"));
s.Registrar(new ObserverConcreto(s, "Z"));
s.SubjectState = "ABC";
s.Notificar();
Console.ReadKey();
}Iniciamos nossos Observers e já passamos como argumento no método Registrar. Quando mudamos o valor de s que é nosso Subject e Notificamos, o método Atualizar() dos Observers é executado e você verá o seguinte resultado:
No .Net também temos uma forma otimizada de fazer isso, usando delegates e events, que é muito mais simples e elegante, mas nada impede você de implementar essas classes da forma que vimos.
Há quem diga que Designs Patterns são na verdade "defeitos" das linguagens, se persarmos bem estão certos. O Observer é seria uma forma de usar delegates e events nas linguagens que não tem esses recursos, assim como vimos com o Singleton que pode ser implementado de forma muito mais simples no .Net. Até a herança que temos hoje, antigamente era um Design Pattern pra linguagens como C. Em assembly tinhamos um Pattern pra criar métodos! Que até então eram codigos que se repetiam por todo o programa, dificultando a manutenção. Mas continuando ao assunto principal...
Delegates são equivalentes aos ponteiros de função, mas orientado à objetos e "type-safe". Uma instncia de delegate mantém uma referência à um método instanciado ou de classe.
Events por sua vez, são construções declaradas numa classe pra ajudar a expor mudanças de estado aos objetos interessados, que são definidos em tempo de execução. Um event representa os métodos Registrar, Desregistrar e Notificar que usamos no Observer, mas suportado diretamente pelo compilador e pela CLR.
Os delegates são registrados pra cada event desejado em tempo de execução e quando o event é chamado, todos os delegates registrados são invocados.
Fazendo uma comparação direta com o Design Pattern Observer, a classe que declara o event, seria o Subject, mas sem precisarmos criar Interfaces. E o Observer deve instanciar um delegate passando o nome do método a ser notificado e registrá-lo ao event. Também é possível desregistrar os delegates. A notificação do Subject acontece quando o event é invocado.
Pra quem não está acostumado com delegates e events pode parecer um pouco complicado, mas na verdade é bem mais simples, pois você não tem que se preocupar com Interfaces ou classes Base. Veja um exemplo:
public class Estoque
{
//Declaração do delegate
public delegate void DelegatePerguntaPreco(decimal pPreco);
//Declaração do event
public event DelegatePerguntaPreco PrecoMudou;
//Variável observada
decimal _Preco;
public decimal Preco
{
set
{
_Preco = value;
//Dispara o event
PrecoMudou(_Preco);
}
}
}
public class TelaEstoque
{
public void MetodoPrecoMudou(decimal pPreco)
{
Console.Write("O novo preço é:" + pPreco.ToString("c") + "\r\n");
}
}
public class MainClass
{
public static void Main()
{
TelaEstoque objTela = new TelaEstoque();//Observer
Estoque objEstoque = new Estoque();//Subject
//Cria novo delegate e associa ao método
//objTela.MetodoPrecoMudou do Observer
Estoque.DelegatePerguntaPreco aDelegate = new
Estoque.DelegatePerguntaPreco(objTela.MetodoPrecoMudou);
//Adiciona o delegate ao event
objEstoque.PrecoMudou += aDelegate;
//Muda o preco 10 vezes
for (int i = 0; i < 10; i++)
{
objEstoque.Preco = i;
}
//Remove o delegate do event
objEstoque.PrecoMudou -= aDelegate;
Console.ReadKey();
}
}
A vantagem dos delegates além da simplicidade é que permite que qualquer classe atue como um Observer, independente das Interfaces implementadas ou da classe Base, só precisamos criar um método com a mesma assinatura do delegate.
