Por favor analizem essa aplicação e comentem

[ualex]

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 ?

[pcalcado]

[quote=ualex]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 ? [/quote]

Vamos lá, devagar.

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

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:

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:

public class Quadrado implements Assunto{
 int aresta;
 Cor minhaCor;
 public void modificar(int novaAresta, Cor novaCor){
   aresta = novaAresta;
   minhaCor=novaCor;
 }
 
 public void registrarObservador(Observador o){
   observadores.add(o);
 }
}

Temos dois observadores interessados nesta classe:

public class Tela implements Observador{
 public void atualizar(Assunto a){
 }
}

public class Calculador implements Observador{
 public void atualizar(Assunto a){
 }
}

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:

 public void modificar(int novaAresta, Cor novaCor){
   aresta = novaAresta;
   minhaCor=novaCor;

   Calculador c = meusOservadores.getCalculador();
   c.atualizar(this, aresta);
    Tela t = meusObservadores.getTela();
     t.atualizar(this, aresta, cor);
 }

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:

 public void modificar(int novaAresta, Cor novaCor){
   aresta = novaAresta;
   minhaCor=novaCor;
 
   calculadora.calcular(novaAresta);
    tela.atualizarQuadrado(aresta, cor);
   
 }

? 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:

public class Quadrado{
...
 public void modificar(int novaAresta, Cor novaCor){
   aresta = novaAresta;
   minhaCor=novaCor;

 for(int i=0;i<observadores.size;i++)
   observadores[i].atualizar(this);

 }
}

public class Tela implements Observador{
 public void atualizar(Assunto a){
    Quadrado q = (Quadrado) a;
    dsenharNovaAresta(a.getAresta());
     aplicarNovaCor(a.getCor());
 }
}

public class Calculador implements Observador{
 public void atualizar(Assunto a){
    Quadrado q = (Quadrado) a;
    recalcular(a.getAresta());
 }
}

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
>