Perguntas sobre MVC Desktop! Existe solução? (+ MVP,MVC WEB,Observer e Exception's)

[sergiotaborda]

[quote=rderoci]Olá pessoal, sou novo aqui e estou cheio de dúvidas… Já lí boa parte do Tópico mas as dúvidas persistem, são elas:

Quanto ao Fluxo do MVC e MVP:

MVC:

1. O Controller recebe ações do usuário, nunca a view?
2. O Controller apenas delega o eventos recebidos da View atualizando o Modelo?
3. Quem notifica a view das mudanças realizadas no Model pelo Controller: O controller? Através do Observer? Ou pelos dois, dependendo de algo que eu não sei? rs
4. O Controller fala com a visão?

MVP:

1. A View é quem recebe ações do usuário, nunca o Presenter?
2. A view notifica o Presenter que delega a atualização/consulta ao Model?
3. Quem notifica a view das mudanças realizadas no Model pelo Presenter: O Presenter? Através do Observer? Ou pelos dois, dependendo de algo que eu não sei? rs
4. O presenter fala com a visão?

Queria saber o processo de cada um deles, assim conseguiria entender mais dos dois e conseguiria tirar uma outra dúvida, qual a diferença entre os 2?

Valeu;[/quote]

O Pedro já respondeu , mas eu queria apenas emendar o seguinte. “Oficialmente” é a View que recebe os eventos do usuário como os cliques e aperto de teclas.
Esses eventos são enviados ao controlador (no mvc) e ele decide o que fazer ( por isso que é o controlador) em relação ao modelo. Ou seja, se deve mudar ou não o modelo.
Por exemplo, quando vc usa um TextField e aperta uma letra a view recebe esse evento e o repassa ao controlador, o controlador então decide passar isso ao modelo (a classe Documet)
O modelo então se atualiza, ou não e se sim, envia um evento. A view recebe esse evento e se re-renderiza para mostrar a letra. VEja que ela não mostra a letra até que o modelo o diga.

No mvp é semelhante, a view recebe os eventos de clique e aperto de teclas, mas agora ela vai transformar isso em gestos. Gestos são eventos que significam algumas coisa especial como salvar, sair, gravar, recarregar, imprimir, etc… e passa esses gestos ao Presenter. A view do mvp é mais inteligente que a do mvc. Ela sabe traduzir cliques “puros” em eventos com significado.
O presenter então responde a esses eventos sem ter que os intrepretar.

a diferença é que o MVC é usado para coisa baixo nivel e por isso é excelente para criar o cliente gráfico ( andar cliente) Mas o cliente é burro. Ele sabe que tem que reagir mas não sabe ao quê está reagindo. O MVP é mais alto nivel ( andar apresentação). O V do mvp pode conter toda uma estrutura sofisticada que pode incluir o MVC inteiro. É isso que vc faz quando usa swing. Vc cria o cliente swing e amarra algumas coisas, o resto vc deixa para outro alguem decidir. Mas todo o cliente swing é a sua view, o decisor é o Presenter. ( Veja, camada de apresentação => presenter)

É importante ter a noção que é a view que recebe os eventos do usuário. É ela que sabe destingir um clique em um butão de um clique numa imagem ou de apertar uma tecla. O fato de ser o controlador ou o presenter a decidir o que fazer, não tira o mérito de ser a view o unico elo de ligação que o usuário tem. A view é o que ele “vê” e ele só vê a view. Digo “vê” por que na realidade a placa de som tb faz parte da view não apenas a tela.

[ingridfarabulini]

Olá rapazes…

Alguém sabe como corrigir o aviso ao clonar os Listener’s? “uses unchecked or unsafe operations”
Ao que parece é um erro de tipagem do ArrayList. É justamente a implementação do pattern Observer.

    public class ModeloEvent extends java.util.EventObject {
       public ModeloEvent(Object source) {
         super(source);
      }
   }

    public interface ModeloListener extends java.util.EventListener {
       void atualizar(ModeloEvent e);
   }

   import java.util.*;
   
    public class Modelo {
    
      private Collection <ModeloListener> modeloListeners = new ArrayList<ModeloListener>();
   
       public void cadastrar() {
         this.notificar();
      }
   	
       public synchronized void addModeloListener(ModeloListener ml) {
         if(!modeloListeners.contains(ml)) {
            modeloListeners.add(ml);
         }
      }
   	
       public synchronized void removeModeloListener(ModeloListener ml) {
         modeloListeners.remove(ml);
      }
   	
       private void notificar() {
         Collection <ModeloListener> ml;
         ModeloEvent evento = new ModeloEvent(this);
           
         synchronized (this) {
            ml = (Collection)(((ArrayList) modeloListeners).clone()); // Será aqui o problema??
         }
      
         for (ModeloListener m : ml) {
            m.atualizar(evento);
         }
      }
   }

Obrigada

[sergiotaborda]

[quote=ingridfarabulini]Olá rapazes…

Alguém sabe como corrigir o aviso ao clonar os Listener’s? “uses unchecked or unsafe operations”
Ao que parece é um erro de tipagem do ArrayList. É justamente a implementação do pattern Observer.

[/quote]

Primeira coisa, não use java.util.EventListener nem java.util.EventObject
Segunda coisa, não use clone.
Terceiro, não precisa ficar copiando a coleção que detem os listeners.
Isso é simplesmente inutil.

A coleção certa para manter os listeners é CopyOnWriteArraySet.
Sendo um Set só uma copia de cada listerns srá registrado. Isso é bom, porque impede que o listerer seja avisado duas vezes do mesmo evento
Por outro ladd esta lista deixa que haja iteração ao mesmo tempo que ha adição e remoção de itens, o que é ideal se, por acaso, algum listener for associado enquando
o loop de disparo do evento estiver corrento. ISto é rarissimo já que a amarração de listeners acontece numa fase de preparação anterior ao real funcionamento, mas
nunca é demais prevenir.

Dê uma olhada numa forma “simples” de trabalhar com eventos.

[rylphs]

Gente, parece que até que enfim estou entendendo melhor MVP e MVC . Obrigado a todos

Ainda tenho uma dúvida: No caso do MVP é o presenter que cria a view e define seu conteúdo? Qual a vantagem disso em uma aplicação desktop?

Digo isso porque estou implementando algo para desktop e pensei em algo como a imagem em anexo. Nesse caso, o presenter criaria a view, mas não definiria seu conteúdo explicitamente em algo como: view.setNome() Ao invés disso se comunicaria com a mesma através do model correspondente. O que vocês acham? Me desculpem pela qualidade da imagem, não sei se dá pra entender a idéia.

[pedromuyala]

Fala rylphs.

Sim, o Presenter instancia a visão e o modelo.

Já em relação a imagem, parece estar bem diferente daquilo que pede o padrão, não?
O Presenter falando diretamente com negócios está estranho. E o modelo da Camada de Apresentação?
Se quer fazer binding direto, esqueça o MVP e MVC e siga o Autonomous view.

Mas acredito que esse link vai te ajudar bastante: http://www.guj.com.br/posts/list/128303.java#795528

Abraço. Poste suas perguntas sem medo de ser feliz!

[sergiotaborda]

[quote=rylphs]Gente, parece que até que enfim estou entendendo melhor MVP e MVC . Obrigado a todos

Ainda tenho uma dúvida: No caso do MVP é o presenter que cria a view e define seu conteúdo? Qual a vantagem disso em uma aplicação desktop?
[/quote]

Não é o presenter que instancia a view. É uma outra classe que não pertence ao MVP, por exemplo a classe onde fica o main.
Esta classe instancia o view, o presenter e o model e os amarra corretamente (faz set ou passa no construtor).
Se usar um motor de injeção é mais facil ainda.

A vantagem é que vc pode sofisiticar a sua view o quanto quiser. pode por exemplo mudar de swing para javafx sem mudar o presenter ou o model.

[quote]
Digo isso porque estou implementando algo para desktop e pensei em algo como a imagem em anexo. Nesse caso, o presenter criaria a view, mas não definiria seu conteúdo explicitamente em algo como: view.setNome() Ao invés disso se comunicaria com a mesma através do model correspondente. O que vocês acham? Me desculpem pela qualidade da imagem, não sei se dá pra entender a idéia.[/quote]

não existe um model que é passado entre a view e o presenter. Existem diferentes beans que são passados. Mas eles não são o M do MVP.

[rylphs]

[quote=pedromuyala]Fala rylphs.

Sim, o Presenter instancia a visão e o modelo.

Já em relação a imagem, parece estar bem diferente daquilo que pede o padrão, não?
O Presenter falando diretamente com negócios está estranho. E o modelo da Camada de Apresentação?
Se quer fazer binding direto, esqueça o MVP e MVC e siga o Autonomous view.

Mas acredito que esse link vai te ajudar bastante: http://www.guj.com.br/posts/list/128303.java#795528

Abraço. Poste suas perguntas sem medo de ser feliz![/quote]

Desculpe, pedro, acho que baguncei um pouco as coisas. O modelo da camada de apresentação seria somente um bean que seria passado pro presenter. O presenter faria a tradução desse bean para o modelo de negócios e vice-versa. O que chamei de business seria algum modelo da camada de negócios (deveria ter colocado “business model”). Como é o presenter que instancia o modeo (pelo menos era o que eu achava até o post do sergiotaborda), inevitavelmente ele teria que se comunicar diretamente com o modelo da camada de negócios. Não é isso? Vou dar uma olhada no “autonomous view” também. Brigadão!

[quote=sergiotaborda]Não é o presenter que instancia a view. É uma outra classe que não pertence ao MVP, por exemplo a classe onde fica o main.
Esta classe instancia o view, o presenter e o model e os amarra corretamente (faz set ou passa no construtor).[/quote]

Eu pensava que o main seria um presenter, ou pelo menos um controller. Nesse caso o main instanciaria todas as views, presenters e models? Não ficaria pouco coeso?
De qualquer forma o presenter não tem que conhecer a view? Não é ele que vai chamar os gets e sets da mesma? Da mesma forma com o model. Ele não teria que conhecer os métodos do model? Então porque não deixar a instanciação por conta do presenter, cada presenter instanciando a view e model que lhe cabe?

Se usar um motor de injeção é mais facil ainda.

Desculpe a minha ignorância, mas o que seria um “motor de injeção”? [tosco on] Alguma máquina a trabalho do ministério da saúde? [tosco off]

Me desculpa se estou falando besteira. Só estou tentando entender melhor as coisas. Obrigado!

[sergiotaborda]

[quote=sergiotaborda]Não é o presenter que instancia a view. É uma outra classe que não pertence ao MVP, por exemplo a classe onde fica o main.
Esta classe instancia o view, o presenter e o model e os amarra corretamente (faz set ou passa no construtor).[/quote]

Eu pensava que o main seria um presenter, ou pelo menos um controller. Nesse caso o main instanciaria todas as views, presenters e models? Não ficaria pouco coeso?

Não. O problema não é coesão, é acoplamento. A coesão é a mesma.

De qualquer forma o presenter não tem que conhecer a view? Não é ele que vai chamar os gets e sets da mesma? Da mesma forma com o model. Ele não teria que conhecer os métodos do model? Então porque não deixar a instanciação por conta do presenter, cada presenter instanciando a view e model que lhe cabe?

Conhecer não significa instanciar.
Conhecer significa -apenas- saber que métodos chamar.

Se usar um motor de injeção é mais facil ainda.

Desculpe a minha ignorância, mas o que seria um “motor de injeção”?

É um mecanismo que constroi os objetos e injeta neles (dá set, ou via construtor) os objetos que ele precisa.
O Spring é um exemplo de um framework que faz isto. (E antes que alguem pergunte: sim. dá para usar spring no desktop)

[rylphs]

Não. O problema não é coesão, é acoplamento. A coesão é a mesma.

Entendo que o acoplamento ficaria menor. Mas o main seria o único a instanciar todas as classes?

E antes que alguem pergunte: sim. dá para usar spring no desktop

Que legal, eu não sabia. Vou pesquisar a respeito.

[sergiotaborda]

[quote=sergiotaborda] Não. O problema não é coesão, é acoplamento. A coesão é a mesma.

Entendo que o acoplamento ficaria menor. Mas o main seria o único a instanciar todas as classes?

[/quote]

Eu usei o main como exemplo. Vc pode criar classes especificas para montarem as classes reais da aplicação.
Isso deve fazer parte da sua plataforma de aplicação , aka infraestrutura.

[ingridfarabulini]

Olá meninos! Tudo bem com vocês?

[quote=sergiotaborda]O problema da sua implementação, Ingrid, é que a classe AgendaControle é na realidade um Presenter e o que vc está tentando fazer é um MVP , não um MVC.
É por isso que está confusa. Vc está fazendo um excelente MVP e achando que é uma porcaria de MVC

    public class AgendaIngrid {
   		
       public static void main(String args[]) {
         AgendaPresenter presenter = new AgendaPresenter();
          // construtores não começam as coisas... 
            presenter.start();
      }
   }

Presenter:

   import java.awt.event.ActionListener;
   import java.awt.event.ActionEvent;

    public class AgendaPresenter {
    
   // só tem acesso ao m e ao v, isso é um presenter. (controles não têm acesso ao v)
      private AgendaModelo m;    
      private AgendaView v;
      
       public AgendaPresenter() {
         
         this.m = new AgendaModelo();
         this.v = new AgendaView();
      	
         m.addModeloListener(
                new ModeloListener() {
                   public void atualizar(ModeloEvent me) {
                        // ok. Veja que este codigo está realmente no presenter 
                       // e ele que está dicidindo o que fazer com o evento

                       v.setPessoa((AgendaBean) me.getSource()));  


                  }
               }); 
      	
         v.addBotaoCadastrar(
                new ActionListener() {
                   public void actionPerformed(ActionEvent ae) {
                          // idem ao de cima
                     m.cadastrar(v.getPessoa()); 
                  }
               });
      }
      
       public void start(){

               // mostra a view 
                  v.setVisible(true);
         }
   }

[/quote]

[quote=sergiotaborda][quote=rylphs]Gente, parece que até que enfim estou entendendo melhor MVP e MVC . Obrigado a todos

Ainda tenho uma dúvida: No caso do MVP é o presenter que cria a view e define seu conteúdo? Qual a vantagem disso em uma aplicação desktop?
[/quote]

Não é o presenter que instancia a view. É uma outra classe que não pertence ao MVP, por exemplo a classe onde fica o main.
Esta classe instancia o view, o presenter e o model e os amarra corretamente (faz set ou passa no construtor).
Se usar um motor de injeção é mais facil ainda.
[/quote]

Fiquei confusa novamente… Lendo as últimas postagens, acreditava que a resposta do Pedro era correta. Até porque no MVP o Presenter está instanciando a minha view e meu modelo…
Pensei que estava excelente. E agora, como vou corrigir isto?

Obrigada…

[victinho]

Pois é, pessoal. Eu acompanhei as postagens da últimas duas páginas e pensava ter entendido bem. Só vim aqui para tirar uma pequena dúvida. Porém, as últimas postagens também me deixaram um pouco confuso. Afinal, a interpretação do mvp pelo rylphs, na minha opinião, foi equivalente ao código postado pela ingridfarabulini.

Se os senhores pudessem fazer uma revisão do que foi discutido desde a página anterior, eu acho que as ambiguidades seriam esclarecidas.

Abraços,
Victor

[pedromuyala]

Opa pessoal, muitíssimo obrigado por estarem atentos ao tópico!
Quero mandar um abraço à todos que estão colaborando.

[quote=rylphs][quote=sergiotaborda] Não. O problema não é coesão, é acoplamento. A coesão é a mesma.

Entendo que o acoplamento ficaria menor. Mas o main seria o único a instanciar todas as classes?

[/quote]

Eu usei o main como exemplo. Vc pode criar classes especificas para montarem as classes reais da aplicação.
Isso deve fazer parte da sua plataforma de aplicação , aka infraestrutura. [/quote]

Como estamos falando de MVP, já que estamos programando em alto nível…
Eu entendo quando o Sérgio diz que é melhor uma classe específica passar as instancias da visão e do modelo para o Presenter.
Sendo assim, o que o Presenter conhece, então, seriam as interfaces da visão e do modelo? É isso que quer passar??
Pois conhecendo somente a interface, também posso trocar a minha visão swing para JavaFX sem ter problemas.

E também acho que a Ingrid está fazendo um excelente MVP. Não é por causa de um pequeno “erro” de instanciação que vamos matar todo o conhecimento que está por trás do código que ela criou. :roll:

Outra coisa, o main é um controlador sim. Um componente do swing também é um controlador. E a visão envia gestos via Observer para o Presenter, pois esses eventos ocorrem de forma assíncrona. Agora aí está minha dúvida: No MVP se tenho dez componentes swing na visão, vamos dizer de JButton’s, se eu clico em um deles o listener que está escutando os eventos desse botão (que está presente na visão) recebe esse evento e então cria um novo evento para que o listener do Presenter o receba? Não né?
A forma que a Ingrid implementou é a correta, certo?

Abraço companheiros, orgulho em tê-los aqui. Muito sucesso e paciência a todos!
Felicidades.

[sergiotaborda]

A instanciação é um assunto separado do MVP, MVC, etc…
É um problema de OO básico.

Quando digo que não é o presenter que instancia eu quero dizer que é melhor fazer assim

    public class Agenda{
   		
       public static void main(String args[]) {
         AgendaView view = new AgendaView();
        AgendaModel model = new AgendaModelo();
       

         AgendaPresenter presenter = new AgendaPresenter(view, model);
          // construtores não começam as coisas... 
            presenter.start();
      }
   }

Em vez de fazer isso dentro do contrutor.
Isso é uma prática OO geral para todos os objetos chamada Inversão de Dependencia.
Porque é legal ?
Porque agora eu posso fazer isto

    public class Agenda{
   		
       public static void main(String args[]) {
         AgendaView view = new NovaAgendaViewMaisBonita();
        AgendaModel model = new AgendaModelo();
       

         AgendaPresenter presenter = new AgendaPresenter(view, model);
          // construtores não começam as coisas... 
            presenter.start();
      }
   }

Viram ? O presenter não mudou nada.
Eu tou usando o mai, mas poderia fazer assim

     public class Configurador(){

               AgendaPresenter presenter;

            public voi configurar(){
              AgendaView view = new NovaAgendaViewMaisBonita();
              AgendaModel model = new AgendaModelo();
       

               presenter = new AgendaPresenter(view, model);
           }

    }
    public class Agenda{
   		
       public static void main(String args[]) {
      
          Configurador conf = new Configurador();

          conf.configurar();

          
           AgendaPresenter presenter = conf.getPresenter();

            presenter.start();
      }
   }

Agora eu posso mudar as classes apenas no configurador assim

     public class Configurador(){

               AgendaPresenter presenter;

            public voi configurar(){
              AgendaView view = new NovaAgendaViewMaisBonita();
              AgendaModel model = new AgendaModelo();
       
               presenter = new AgendaPresenterComNovasRegras(view, model);
           }

    }

Sim, é muito bom que AgendaView , AgendaModel e AgendaPresenter sejam interfaces. Não é obrigatório, mas é muito melhor design, porque é ainda mais desacoplado.
Alta coesão, baixo acoplamento. Esse é sempre o objetivo de todos os designs OO.

Como disse o Pedro, este detalhe da inicialização das classes não mancha o design MVP feito. É apenas a cereja no topo do sorvete… (mas uma cereja que deveria estar no topo de todos os sorvetes … inversão de dependencia é uma prática básica de OO em qq camada, em qualquer arquitetura, em qualquer linguagem ou plataforma)

[victinho]

Olá, senhores. Obrigado pelos esclarecimentos.

Eu tenho uma dúvida:

Se eu tiver uma classe JFrame com JInternalFrame’s, eu posso ter uma classe presenter para cada JInternalFrame? No meu caso, ainda tenho, em um dos JInternalFrame’s, um JDialog. É, resumidamente, assim:

Presenter para a janela principal:

[code]public class PrincipalPresenter{

private PrincipalView principalView;
//atributos
//métodos
}[/code]

A classe model Formulario:

[code]public class Formulario{

private List questao;
//atributos
//métodos
}[/code]

Eu tenho um JInternalFrame que tem FormularioView, FormularioPresenter, etc. Em FormularioPresenter eu também tenho um objeto Formulario.

[code]public class FormularioPresenter{

private FormularioView formularioView;
private Formulario formulario; //model
private QuestaoPresenter questaoPresenter;
//atributos
//métodos
}[/code]

Associado a esse JInternalFrame, eu tenho uma classe JDialog, mais precisamente, QuestaoView, com seus respectivos QuestaoPresenter, etc.

[code]public class QuestaoPresenter{

private QuestaoView questaoView;
private Questao questao; // model
//atributos
//métodos
}[/code]

A pergunta: como eu faço para informar o objeto Formulario sobre os objetos Questao inseridos a partir de QuestaoView?

Desculpem-me se não fui claro!

Abraços,
Victor

[ingridfarabulini]

Olá meninos, oi Sérgio
Obrigada moço, entendi direitinho o que quis expor…

[quote=sergiotaborda]
A instanciação é um assunto separado do MVP, MVC, etc…
É um problema de OO básico.

Sim, é muito bom que AgendaView , AgendaModel e AgendaPresenter sejam interfaces. Não é obrigatório, mas é muito melhor design, porque é ainda mais desacoplado.
Alta coesão, baixo acoplamento. Esse é sempre o objetivo de todos os designs OO.

Como disse o Pedro, este detalhe da inicialização das classes não mancha o design MVP feito. É apenas a cereja no topo do sorvete… (mas uma cereja que deveria estar no topo de todos os sorvetes … inversão de dependencia é uma prática básica de OO em qq camada, em qualquer arquitetura, em qualquer linguagem ou plataforma)[/quote]

Vou implementar o meu novo código seguindo sua orientação e voltarei a postar.
Mas vou estudá-lo antes de sair fazendo qualquer coisa. Muito obrigada, agradeço a todos.

[ingridfarabulini]

Olá meninos, tudo bem com vocês?

Quem chegou a ler minha postagem anterior, provavelmente esteve aguardando aquilo que falei… pois agora sim, fiz um verdadeiro MVP (pelo menos acredito que sim)
Fiz todas as alterações certinhas indicadas pelo Sergio… tanto no Observer quanto na Inversão de Dependência.

   public class AgendaIngrid {
     
       public static void main(String args[]) { 
       
         AgendaConfig conf = new AgendaConfig();
         conf.config();
         AgendaPresenter presenter = conf.getPresenter();
         presenter.start(); 
      } 
   } 

    public class AgendaConfig { 
    
      AgendaPresenter presenter; 
       
       public void config() { 
         AgendaView view = new AgendaView();
         AgendaModelo model = new AgendaModelo();
         
         presenter = new AgendaPresenter(model, view);
      }
   	
       public AgendaPresenter getPresenter() {
         return presenter;
      }
   } 

   import javax.swing.*; 
   import java.awt.event.*;
	 
    public class AgendaView extends JFrame { 
      private JTextField nome, eMail, telefone; 
      private JButton bCadastrar; 
   
       public AgendaView() { 
         JPanel p = new JPanel(); 
         p.add(new JLabel("Nome:")); 
         p.add(nome = new JTextField(10)); 
         p.add(new JLabel(" - Telefone:")); 
         p.add(telefone = new JTextField(10)); 
         p.add(new JLabel(" - E-Mail:")); 
         p.add(eMail = new JTextField(10)); 
         p.add(bCadastrar = new JButton("Cadastrar Pessoa >>")); 
         add(p); 
         setTitle("Agenda Ingrid vs1.1"); 
         setSize(720,70); 
         setResizable(false); 
         setDefaultCloseOperation(EXIT_ON_CLOSE); 
      } 
   	
       public void setPessoa(AgendaBean ab) { 
         this.nome.setText(ab.getNome()); 
         this.telefone.setText(ab.getTelefone()); 
         this.eMail.setText(ab.getEMail()); 
      } 
   	
       public AgendaBean getPessoa() { 
         AgendaBean ab = new AgendaBean(); 
         ab.setNome(this.nome.getText()); 
         ab.setTelefone(this.telefone.getText()); 
         ab.setEMail(this.eMail.getText()); 
         return ab; 
      } 
   	
       public void addBotaoCadastrar(ActionListener al) { 
         bCadastrar.addActionListener(al); 
      } 
   } 

   import java.awt.event.ActionListener; 
   import java.awt.event.ActionEvent; 

    public class AgendaPresenter { 
   
      private AgendaModelo m; 
      private AgendaView v; 
   
       public AgendaPresenter(AgendaModelo model, AgendaView view) { 
         this.m = model; 
         this.v = view; 
      
         m.addModeloListener( 
                new ModeloListener() { 
                   public void onAtualizar(ModeloEvent me) { 
                     v.setPessoa((AgendaBean) me.getSource()); 
                  } 
               });
      			 
         v.addBotaoCadastrar( 
                new ActionListener() { 
                   public void actionPerformed(ActionEvent ae) { 
                     m.cadastrar(v.getPessoa()); 
                  } 
               }); 
      }
   	 
       public void start(){ 
         v.setVisible(true); 
      }
   	 
   } 

   import java.util.*;
   import java.util.concurrent.*;
   
    public class AgendaModelo {
    
      private AgendaBean b;
   	    
      private final Set<ModeloListener> modeloListeners = new CopyOnWriteArraySet<ModeloListener>(); 
   
       public void cadastrar(AgendaBean b) {
         this.b = b;
      	// Acessa a camada inferior para persistir...
         this.fireOnAtualizar();
      }
   	
       public void addModeloListener(ModeloListener ml) {
         this.modeloListeners.add(ml);
      }
   	
       public void removeModeloListener(ModeloListener ml) {
         this.modeloListeners.remove(ml);
      }
   	
       private void fireOnAtualizar() {
         ModeloEvent evento = new ModeloEvent(b);
      
         for (ModeloListener ml : modeloListeners) {
            ml.onAtualizar(evento);
         }
      }
   }

    public class AgendaBean {
    
      private String nome, eMail, telefone;
   
       public AgendaBean() {
         this.nome="N/C";
         this.eMail="N/C";
         this.telefone="N/C";
      }
   	
       public void setNome(String nome) {
         this.nome = nome;
      }
   		
       public String getNome() {
         return this.nome;
      }
   	
       public void setEMail(String eMail) {
         this.eMail = eMail;
      }
   	
       public String getEMail() {
         return this.eMail;
      }
   	
       public void setTelefone(String telefone) {
         this.telefone = telefone;
      }
   	
       public String getTelefone() {
         return this.telefone;
      }
   }

    public interface ModeloListener {
       void onAtualizar(ModeloEvent e);
   }

    public class ModeloEvent {
    
      Object source;
   	 
       public ModeloEvent(Object source) {
         this.source = source;
      }
   	
       public Object getSource(){
         return source;
      }
   }

EEEEBBBAAA! Agora simmm… :lol:
Lembrando que ainda falta implementar as interfaces para Modelo, Visão e Presente para ter um melhor design!

Mas ainda tenho uma dúvida…
Veja a linha 16 do AgendaPresenter…

                  v.setPessoa((AgendaBean) me.getSource());   

Aí minha pergunta é: A classe ModeloEvent tem um atributo do tipo Object. Ele poderia já ser do tipo AgendaBean :?:

Outra pergunta é: Dessa forma que está o código, está fácil para qualquer outro(a) programador(a) entender caso precise fazer alterações? Ou seja, é um MVP claro?
Existe algo que está visivelmente errado em termos de programação e padronização de OO e MVP?
O bean faz parte de qual camada? Eu sei que ele não é o M do MVP que está na camada de apresentação mas ele é de qual camada?

Obrigada meninos! Quero muito agradecer pela ajuda de todos que continuam ajudando.

[sergiotaborda]

EEEEBBBAAA! Agora simmm… :lol:
Lembrando que ainda falta implementar as interfaces para Modelo, Visão e Presente para ter um melhor design!

Mas ainda tenho uma dúvida…
Veja a linha 16 do AgendaPresenter…

                  v.setPessoa((AgendaBean) me.getSource());   

Aí minha pergunta é: A classe ModeloEvent tem um atributo do tipo Object. Ele poderia já ser do tipo AgendaBean :?:

Quando se usa o “getSource” está se à espera que o retorno seja o objecto que deu origem ao evento.
A incongruencia vem dai. Vc não está usando para isso. Portanto , renomei o método para getAgenda e retorne um agenda bean.

Outra pergunta é: Dessa forma que está o código, está fácil para qualquer outro(a) programador(a) entender caso precise fazer alterações? Ou seja, é um MVP claro?
Existe algo que está visivelmente errado em termos de programação e padronização de OO e MVP?

Algumas nomenclauturas, por exemplo get/setPessoa na realidade fazem get/set de AgendaBean. Ou troca para get/set agenda ou muda o objeto para Pessoa.
Outra questão de nomenclatura é não se coloca o sufixo bean nos beans. Apenas Agenda é suficiente.

O bean faz parte de qual camada? Eu sei que ele não é o M do MVP que está na camada de apresentação mas ele é de qual camada?

Essa pergunta é mais dificil do que parece. Se o bean é apenas usado para o MVP então ele pertence na camada de apresentação.
Se o bean é usado por outras camadas então ele pertence na camada de dominio ( abaixo da apresentação). Na realidade ele não pertene fisicamente à camada de dominio, já que ele transita por todas as camadas, mas pertence a ela lógicamente.

[ingridfarabulini]

Olá Sergio, obrigada por responder!
Fiz as alterações que me ensinou… que bom estar agora certinho.

Ah e também deixei o Bean com o nome Pessoa. Achei melhor porque a agenda é um grupo de pessoas com determinada organização alfabética.
Essa organização que é a Agenda (cadastrar, consultar,…). Não sei se estou pensando corretamente , mas …
Poderia ser uma agenda de compromissos. No lugar de pessoas, teria o Bean Compromisso. Acho eu

Vou estudar a camada de domínio para definir onde esse Bean deverá pertencer…
Se voltar a ter dúvidas voltarei a postar aqui mesmo.

Obrigada, você me ajuda sempre! T+

[pedromuyala]

Opa pessoal, prazer estar aqui com vocês companheiros Gujeiros!
Estive acompanhando o desenrolar deste tópico parece que estamos chegando ao um acordo real do que é MVP.

:roll: Nesse meio todo surgiu uma dúvida: No MVP, caso ocorra uma excessão no modelo por invalidação de algum dado ou até mesmo um erro diferente, ele deve lançar uma exception correto? Mas essa exceção será o Presenter quem deve estar preparado para receber e após isso repassar a View (throws em ambos) e ela se encarregará de como mostrará isso ao usuário ou o próprio modelo deverá ter um atributo de mensagem de erro e o Presenter será avisado pelo evento do Observer que ele (o modelo) foi alterado e deve reenderizar a visão para mostrá-lo ao usuário? [color=orange]OBS: Isso já foi discutido aqui no tópico mas foi falado em relação ao MVC e nunca ao MVP.[/color]

Olha quero desejar felicidades a todos os companheiros é um sonho realizado para mim ver que as pessoas estão interessadas pelo tópico. :thumbup:
É realmente deslumbrante para mim. Felicidades a todos muito sucesso parabéns a adm do GUJ e seus moderadores pelo ambiente agradabilíssimo disponível aqui.