Por favor analizem essa aplicação e comentem...

Mais ou menos. A Sun chama DTO de Transfer Object, mas costumava chamar de VO. Só qeu DTO é um pattern do Fowler, não da Sun.

Para implementar um Observer, o observer tem que saber sobre o assunto. No seu caso, o Assunto é o DTO, não o Objetos de Negócio em si. exemplo:

JavaGuru Membro desde: 26/08/2004 18:45:26 Mensagens: 229 Offline

tudo bem esse getDTO vai devolver um DTO, que nesse caso seria o segundo argumento argumento do metodo update(Observable o,Object o).

parece que rodamos e chegamos no mesmo lugar

Não, a questão é que não existe motivo para você passar dois parâmetros.

[]s

JavaGuru Membro desde: 26/08/2004 18:45:26 Mensagens: 229 Offline

tipo o observer não só para notificar sobre mudanças. ele também tem que avisar sobre o que mudou porque afinal é isso que interessa

tipo como se alguem falasse para vc mudei, e dai ? ele tem que falar o que mudou. e passar mais informação entendeu é muito vago falar só mudei. E o primeiro argumento
java.util.Observer.update(Observable o,Object o) fala isso que ele mudou e mais algumas coisas mas ele não devolve o objeto que mudou(não existe um getSource). acho que por isso existe o segundo parametro para vc enviar a informação que for mais conviniente.

Assim você causa acoplamento.

O padrão observer supõe que existem diversos observadores,c ada um interessado em um ou outro aspecto.

Do jeito que você falou, quem avisa os observaores da mudança de estado 9que geralmente é o próprio assunto) tem que saber o que cada observador está interessado na classe, e passar para ele.

E já que é para passar, seria muito mais interessante passar apenas o que foi mudado. Se você não rpecisa da referência ao objeto para que o observador saiba o que mudou, para que passá-la?

Seu padrão pode ser substituído por uma simples chamada de método.

Não sei onde a Sun usa isso, se você achar um código que use para comentarmos, cola ai

[]s

JavaGuru Membro desde: 26/08/2004 18:45:26 Mensagens: 229 Offline

então essa sua ideia de passar só que for mudado dae cria um acoplamento mais forte. Porque então o observado teria que notificar observadores diferentes.

é muito mais facil o observado passar uma referência dele para cada observador pegar as informações que interessa a eles.

acho que assim não ta errado. só talvez eu poderia fazer diferente neste caso ?

ualex wrote:então essa sua ideia de passar só que for mudado dae cria um acoplamento mais forte. Porque então o observado teria que notificar observadores diferentes.

é muito mais facil o observado passar uma referência dele para cada observador pegar as informações que interessa a eles.

acho que assim não ta errado. só talvez eu poderia fazer diferente neste caso ?

Vamos lá, devagar.

O Padrão Observer, da GoF, define estas colaborações:

GoF wrote:
# ConcreteSubject notifies its observers whenever a change occurs that could make its observers' state inconsistent with its own.

# After being informed of a change in the concrete subject, a ConcreteObserver object may query the subject for information. ConcreteObserver uses this information to reconcile its state with that of the subject.

The following interaction diagram illustrates the collaborations between a subject and two observers:

Note how the Observer object that initiates the change request postpones its update until it gets a notification from the subject. Notify is not always called by the subject. It can be called by an observer or by another kind of object entirely. The Implementation section discusses some common variations.

Existe uma variação para múltiplos Assuntos (Subjects), definida assim:

GoF wrote:
Observing more than one subject. It might make sense in some situations for an observer to depend on more than one subject. For example, a spreadsheet may depend on more than one data source. It's necessary to extend the Update interface in such cases to let the observer know which subject is sending the notification. The subject can simply pass itself as a parameter in the Update operation, thereby letting the observer know which subject to examine.

Eu pessoalmente usaria polimorfismo para observar os assuntos, mas parece quee sta variação que a Sun implementou na interface.

Agora vamos ao acoplamento.

Existe uma classe Quadrado:

Temos dois observadores interessados nesta classe:

Sendo que Tela está interessado no tamanho da aresta e na cor do quadrado, enquanto Calculador só se interessa pela aresta. Seguindo seu raciocínio, teríamos:

Esqueça o número de parâmetros por enquanto. A primeira coisa ruim aqui é que a classe observada tem que conhecer seus observadores, afinal ela precisa saber o que eles querem saber dela. Só isso já causou uma dependência totalemnte desnecessária entre o Quadrado e as outras classes, o padrão observer é extamente para evitar isso. Na verdade, qual a diferença disto para:

? Entre uma e outra, zero. A diferença disso para um sistema OO é que quando você lida com objetos, você passa objetos, não parâmetros atômicos que não dizem nada sozinhos, por isso este tipo de coisa vai contra a OO.

Agora vamos ver a implementação normal de um observer:

Assim as classes observadoras dependem do assunto (o que pdoe ser amenizado numa hierarquia de classes bem definida), mas não o contrário.

Você deve:

1) Evitar passar parâmetros atômicos
2) Evitar implementar Observer para passar parâmetros, ele nao é bom nisso (nem deveria)
3) Evitar que sua classe Assunto dependa de seus observadores

[]s
>

Notícias, artigos e o maior fórum brasileiro sobre Java