Document Management vs Knowledge Management

Download Report

Transcript Document Management vs Knowledge Management

PR
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
CURSO DE ESPECIALIZAÇÃO
EM TECNOLOGIA JAVA
DESIGN PATTERNS
PARTE 2: PADRÃO OBSERVER
Prof. Cesar Augusto Tacla
http://www.dainf.ct.utfpr.edu.br/~tacla
UTFPR/Campus Curitiba
◊ Para entender o padrão
Observer utilizaremos o
modelo de eventos do AWT
(que implementa o Observer).
◊ Em seguida, implementaremos
nosso próprio padrão Observer
num exemplo didático.
◊ Finalmente, faremos exercícios
que modificam este exemplo
didático.
◊ Tópicos relacionados:
desacoplamento das camadas
view e controller do padrão
MVC
2
Desacoplamento
 Desacoplar é reduzir as dependências entre classes
 Exemplo: no modelo de eventos Swing
 Eventos são gerados e tratados de forma padrão
 O evento botão pressionado pode ter vários observadores
 O botão não sabe quantos e nem quais são os observadores
3
Modelo de eventos swing
Objeto
observador
Registra-se
Objeto
observador
notifica
Botão pressionado
Esquema geral do model de eventos swing segue
o padrão observer: podemos ter vários
observadores de eventos do botão, mas para o
botão isto é indiferente!
4
Modelo eventos: subject
◊ Botão é denominado subject (assunto)
◊ Possui vários observadores, no exemplo, o objeto
referenciado por ctrlAssinatura
JButton button = new JButton(“Clique-me”);
button.addActionListener(ctrlAssinatura);
adicionar
Lista de observadores
5
Modelo eventos: observer
◊ Observador deve se registrar no sujeito e tratar os
eventos dos quais recebe notificação.
◊ actionPerformed no Observer faz exatamente isto
1.
2.
3.
4.
5.
6.
7.
public void actionPerformed(ActionEvent e) {
String s = new String(e.getActionCommand());
numCliques++;
System.out.println("Botao [" +
e.getActionCommand() + "]
clicado: " + numCliques);
}
6
Modelo de eventos swing
addActionListener(this)
Objeto
observador
actionPerformed(ActionEvent e)
Botão pressionado
7
Modelo de eventos: notificação
Usuário
AWT
Abstract Window
Toolkit
Botão Subject
Gerador de eventos
Observador
Clica no
botão
AWT envia uma
instância de
ActionEvent para o
botão chamando o
método processEvent
Executa o método
processEvent que
recebe todos os
eventos do botão e
passa o evento aos
observadores da lista
Executa o método
ActionPerformed
8
Exercícios
◊ Exercício 1
 Baixe o código JContador, compile-o e execute-o
http://www.dainf.ct.utfpr.edu.br/~tacla/JAVARepositorio/JMVCObserver/JContador/
 Em seguida, modifique-o incluindo os botões: “clique-me 1” e “clique-me 2”.
 Faça com que a instância de CtrlContador escute eventos que ocorram nestes
novos botões. Tente diferenciar os cliques mostrando um contador de cliques
diferente para cada botão.
◊ Exercício 2
 quando o usuário clicar no botão “clique-me 2”, remover a instância de
CtrlContador da lista de ouvidores de eventos do botão “clique-me 2”.
Solução: JContador-ex1
◊ Exercício 3
 Observar no diagrama de classes os participantes do padrão observer
marcados em vermelho.
 Observer no diagrama de sequência a colaboração entre os participantes
 (CtrlAssinatura equivale a CtrlContador)
9
Observador
Sujeito
AbstractButton
Sujeito
concreto
Observador
concreto
10
janela
11
APLICAÇÃO DO OBSERVER
◊ Quando uma modificação do estado de um objeto implica
modificações em outros e
◊ Quando um objeto deve ser capaz de notificar outros objetos,
mas sem pressupostos sobre os objetos a serem notificados
(caso da implementação do AWT). Isto é, não é desejável um
forte acoplamento com os objetos que necessitam conhecer
estas modificações
◊ (Gamma et al., 1995, pg. 294)
12
PARTICIPANTES
◊ Sujeito (subject):
 Conhece seus observadores.
 Um número qualquer de observadores é permitido.
 Provê uma interface para adicionar/remover observadores (ex.
addActionListener e removeActionListener em AbstractButton)
◊ Observador (observer):
 Define uma interface de atualização para os objetos que devem ser notificados
sobre as mudanças no sujeito.
◊ Sujeito concreto (ConcreteSubject)
 Armazena estado de interesse para os objetos de ObserverConcrete
 Envia uma notificação aos observadores concretos quando seu estado muda.
◊ Observador concreto (ConcreteObserver)
 Implementa a interface definida pelo Observador para tratar as notificações
13
OBSERVER: generalização da idéia
◊ Vimos no exemplo anterior que objetos JButton geram
eventos de interface (instâncias da classe ActionEvent) que
podem ser observados por objetos ActionListener.
◊ Pergunta-se: como fazemos para que um objeto de uma classe
qualquer (que não faça parte do AWT) crie seus eventos e
que esses eventos sejam escutados por outros objetos?
Sistemas Distribuídos/UTFPR Prof. Cesar Augusto Tacla
14
OBSERVER: generalização da idéia
◊ Exercício 1:
 baixe o código JGeradorEventos, compile-o e execute-o. Esta versão
não tem o Subject (abstract)

http://www.dainf.ct.utfpr.edu.br/~tacla/JAVARepositorio/JMVCObserver/JGeradorEventos/
 modifique-o incluindo mais dois objetos ouvidores que sejam
notificados dos eventos gerados.
 Uma versão tal qual o padrão está disponível em

http://www.dainf.ct.utfpr.edu.br/~tacla/JAVARepositorio/JMVCObserver/JGeradorEventos-v2/
◊ Exercício 2:
 Construa o diagrama de classes

Solução em http://www.dainf.ct.utfpr.edu.br/~tacla/EspDesignPatterns/sol1/JGeradorEventos.pdf
 Construa o diagrama de seqüência para o cenário seguinte: o gerador
de eventos gera um evento e dois objetos instâncias da classe Ouvidor
são notificados.
Sistemas Distribuídos/UTFPR Prof. Cesar Augusto Tacla
15