Padrões GOF (Padrão Oberver)

Aulas 20 e 21

Em um sistema orientado a objeto, o foco principal é a comunicação entre os objetos, e os padrões que já estudamos anteriormente tratam bem dessa questão, e não é diferente com o que vamos ver a seguir.

Geralmente, um objeto coleta informação de outro chamando seu método, no entanto, quando um objeto muda, os objetos clientes não têm como saber se aquele objeto mudou e assim o cliente pode deixar de utilizá-lo. O padrão Observer permite que objetos interessados (clientes), sejam avisados da mudança de estado ou evento ocorrendo em outro objeto. A intenção é definir uma dependência um-para-muitos, assim, quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente.

Em java.swing o objeto que está sendo observado (aquele que pode mudar) é chamado de “Source”, e o objeto que observa (o objeto que está interessado, o cliente), é chamado de “Listener”.

Existem muitas controvérsias quanto ao uso deste padrão, principalmente entre as soluções dadas pelo GOF, baseada em java swing e as soluções apresentadas por autores que seguem a implementação em java, em especial Bill Venners, portanto, vale analisarmos as soluções da cada um para entendermos, no link a seguir, encontra-se um exemplo que segue o paradigma de Bill Venners, e no diagrama uml encontra-se as definições do GOF, onde o observer é o objeto que observa, e subject, aquele que é observado.

Em Java, um objeto (o Source/Subject ) envia informação para outro objeto (o Listener/Observer) pela chamada de um método do Listener/Observer. Mas, para que isso seja possível:

• O Source/Subject deve ter uma referência ao Listener/Observer.
• O tipo desta referência deve ser uma classe ou interface que declare ou herde o método a chamar

Fazer com que o tipo da referência seja a classe (concreta) do Listener/Observer não funciona bem, porque:

• O número e tipos dos Listeners/Observer não é conhecido em tempo de compilação
• Os vários listeners/Observers poderão não fazer parte de uma mesma hierarquia de objetos
• Não queremos criar um acoplamento forte entre Source/Subject e Listeners/Observers.

A solução vai se basear primordialmente em interfaces para resolver o problema

• Aliás, este é um excelente exemplo do poder de interfaces para prover polimorfismo envolvendo classes não relacionadas por herança (de implementação)

A seguir temos um diagrama UML que demonstra a utilização de interfaces para servir como referência ao Source/Subject, ao invés da sua classe concreta.

REFERÊNCIAS

UFCG, Artigo, Padrão Observer segundo Bill Venners