Olá meninos 
Primeiro quero agradecer o interesse de vocês em tentar me ajudar. Fico muito feliz Obrigada Sergio em responder minhas dúvidas.
Segundo peço desculpas se minhas perguntas causaram um certo ‘desconforto’ gerando discussão entre os usuários que estão colaborando 
Mas no geral estou muito feliz pela ajuda e atenção que estão tendo ao tópico tentando sempre ajudar 
Ainda tenho algumas dúvidas que postarei logo após a próxima postagem…
Obrigada
Olá luistiagos… tudo bem com você moço? 
[quote=luistiagos]incrivel que quando chega um cueca e faz alguma pergunta do tipo… se meia duzia responder é muito…
agora com uma menininha gatinha de rostinho angelical pergunta temos 4 paginas so de resposta… interessante não… mas o mais interessante é que dificilmente menininhas bonitinhas se interessam por tecnologia e muito menos por qualquer area de extas e muito menos ainda computação… com algumas exceções como a lina por exemplo… imagino que deve ter muito neguinho aqui fazendo avateres com fotos de menininhas lindinhas para pegar muito otaria no forum… bem não creio que seja o caso da ingrid pois esta fez uma pergunta coerente e não algo como: “porfavor façam meu dever de casa…” dai sim seria meio suspeito…[/quote]
Luis, posso causar uma admiração a você neste momento, mas concordo com a sua forma de enxergar e entender o que falou na citação acima… mas não concordo com você como pessoa.
Eu lí muitas das suas postagens no fórum sempre com a intensão de ajudar o próximo e por aí concluí que como pessoa você é muito mais do que isso que falou na citação acima.
Como mulher, posso dizer que se analizarmos a sociedade atual na qual vivemos sou obrigada a concordar com você quando diz que as mulheres tem preferência sobre os homens na visão masculina. ( Ahh, obrigada pelo elogio da foto, fico feliz em me enxergar assim como citou. :oops: A maioria dos amigos/colegas quando me vêem pela primeira vez me acham ‘orgulhosa/patricinha’ 
)
Mais uma vez, como mulher, posso te afirmar com toda clara certeza deste mundo que Deus construiu para nossa existência que ‘menininhas bonitinhas’ se interessam sim por tecnologia e pela área de exatas… e olha que basta fazer uma busca simples para encontrá-las. Basta assistir palestras de tecnologia, ler bibliografias de artigos em revistas especializadas, participar de fóruns na Internet como o GUJ, entrar em uma sala de aula na faculdade/universidade/cursos profissionalizantes ou em qualquer curso de exatas e assuntos relacionados a área de tecnologia logo encontrará uma ‘menininha bonitinha’, na sua forma de enxergar ( igual a Lina, como lembrou ) . Mesmo as mulheres sendo a minoria na área nós somos reais e buscamos coisas que qualquer ser humano busca na área independete do sexo.
Não posso afirmar uma coisa que obviamente pode acontecer a qualquer momento mas não acredito ( e nem gostaria de acreditar ) que em um mundo onde todas as pessoas deveriam ser igualmente respeitadas, independentemente de classe, cor, religião, beleza e sexo seja necessário alguém se submeter a tal constrangimento pessoal e mental para conseguir chamar a atenção das outras pessoas. Por isso muitas vezes imaginei que nasci em um planeta errado… Acho que a maldade está mais nos olhos de quem vê.
Ahh eu sei muito bem disso lindo… hihihihihi… Já pensou amanhã ou depois aparece a foto de um rapaz no meu avatar dizendo: “Valew ae mano!” hihihihihihi… Fico só imaginando a carinha dos colegas.
Mas quero continuar acreditando que ainda existe gente muito boa e da melhor qualidade nesse mundo com lindas almas… mesmo sabendo, assim como você, que o mundo não é assim tão lindo… mas vamos continuar lutando para que ele seja, não? Não seria muito melhor ver mulheres nos programas de TV explicando alguma novidade do mundo Java no lugar de ficarem mostrando os seus lindos corpos siliconados produzidos pelos melhores cirurgiões plásticos existentes?
Ah… mulher fala né? :mrgreen: Desculpe mas me chamou atenção a sua postagem que, volto a dizer, é algo que pode ser uma realidade sim e pode estar acontecendo… quem sabe não?
Acho que para que isso nunca aconteça, seria necessário a administração do fórum providenciar um cadastro real e ao vivo de todos aqueles que quiserem participar apresentando documento e coisas do gênero. Mas acho completamente inviável e uma loucura levar algo ‘tão à risca’ assim… :roll: Legal é o fórum ser público como está hoje onde sempre novas pessoas participam e trocam idéias e conhecimentos sem muitas restrições. O objetivo aqui é ajudar, independentemente da fotinho que aparece no avatar de cada um.
Você mesmo se for no desenho da sua foto no avatar uma realidade física, não acha que sua foto chamaria a atenção das usuárias do fórum? Pense nisso.
Tem coisas que são reais e não existe nenhum outro interesse por trás delas, está entendendo? Com certeza no momento que abriu este tópico você tinha somente a intensão de ajudar/ler/opinar ( ainda não tinha visto minha foto ) mas devido a essa sua má interpretação ( que volto a dizer, é uma realidade a qualquer momento ) sem querer deixou desviar o foco. Mas vou fazer o que, meu Deus! Não seria muita falsidade minha colocar uma foto de outra pessoa que na minha visão ( cada um tem a sua ) aparentemente não agradace os demias usuários só para não causar esse tipo de problema que resolveu expor?
Eu só sai mais em defesa de todas as mulheres que precisam ser mais ‘bem vindas’ em áreas as quais não tinhamos tanto acesso ou sofriamos algum tipo de preconceito.
Talvez você nunca mais abra este tópico e nem leia isso que estou falando, mas fica aí a reflexão… Até + Obrigada
Olá Sergio
Aí puxa vida, é verdade… :roll: me desculpe fazê-lo repetitivo, perdão.
[quote=sergiotaborda][quote=ingridfarabulini]E um detalhe que reparei que também preciso definitivamente saber a resposta:
5) No MVC, quem tem a responsabilidade de se comunicar com o andar abaixo é a letra C ( como no exemplo Swing que citei acima ) mas no MVP quem fala com o andar abaixo é a letra M ( como foi explicado naquele famoso gigante tópico de MVP + MVC +… ). Estou certa?[/quote]
Não. todos os listenerns são models do MVC do swing. Mais especificamente o Action é o model de botões e outras coisas “clicáveis” como menus, por exemplo. Ele implementa ActionListener mas ele controla mais coisas, como por exemplo o Enabled. SEMPRE é o model que comunica com o andar de baixo.
Neste momento vc está procurando cabelo em ovo. Já lhe expliquei antes que no listener vc coloca a chamada ao presenter e pronto. Não ha mais truques.[/quote]
Agora eu entendi certinho como funciona… hihihihi
Nossa mas que legal… vou aplicar essas explicações todas na Agenda para mostrar o código aqui
Um detalhe que achei interessante é que nesses dois andares (Cliente e Apresentação) não foi necessário em nenhum momento usar aquelas coisas horríveis de TO/DTO para ligar ambos andares :idea: o que é bom, não? Visto que é uma coisa que não é mais usada para coisas novas, estou certa?
Obrigada Até +…
[quote=bobmoe][quote=ingridfarabulini]
Faz pouquíssimo tempo que estudo Java ‘um ano e meio aprox.’ e sempre escrevi meus programas sem seguir nenhum pattern ou qualquer tipo de arquitetura. Mas de uns meses para cá estou interessada em seguir alguns padrões mínimos para um bom desenvolvimento ‘ou pelo menos que facilite a vida de qualquer programador(a) quando necessário realizar alguma manutenção neste código’. Pensando nisso iniciei meus estudos com o pattern Layers, ou camadas lógicas, como preferir.
[/quote]
quem aprende design patterns só estudando, se torna péssimo programador; o q complica coisas simples. durante sua experiencia naturalmente vai reconhecer a necessidade.
não precisa ir atrás de design patterns, eles vem até vc
editado:
lógico, estou dizendo isso partindo do principio q vc é inciante.
[/quote]
Concordo com o bobmoe.
Vantagens e desvantagens do padrão Layers:
Advantages
Disadvantages
Quero só ver esse código…
[quote=ceklock][quote=ingridfarabulini]
Nossa mas que legal… vou aplicar essas explicações todas na Agenda para mostrar o código aqui
[/quote]
Quero só ver esse código…
[/quote]
Olá ceklock, tudo bem?
Percebi que você também é iniciante ( assim com eu ) em Java pelas suas postagens anteriores então vai minha dica: não se apegue muito aos códigos. Até entendo quando diz que aprender padrões e mais padrões vai ser prejudicial… mas ficar tentando entender códigos e mais códigos você acabaria caindo naquela frase mesmo que falou “padrão, cada um tem o seu”. No lugar de inovar com os padrões já existentes, você passaria a maior parte do seu tempo aprendendo os padrões de bilhões de pessoas mundo afora, fugindo da sua habilidade de inovar com coisas já existentes. Ok moço? Eu comecei a me interessar por padrões exatamente para não causar mais sustos nas pessoas quando olhavam para o meu código e se assustavam sem entender absolutamente nada com classes super extensas e outros problemas.
Espero que continue sim sempre que puder participando do tópico e mandando suas postagens Até + …
Bem, chegando atrasado, mas vou dar a minha contribuição aqui:
Todos os padrões de projeto (inclusive o MVC) tem a característica de criar soluções reutilizáveis para problemas recorrentes. Mantenha isso sempre em mente.
É importante também aprender princípios de orientação a objetos, que são a base para todos (ou quase todos) os padrões em POO: Encapsulamento, polimorfismo, alta coesão e baixo acoplamento. “Law of Demeter” também é uma importante consequência disso. Um projeto bem feito de verdade deve seguir estes princípios, e os padrões de projeto acabam surgindo mais ou menos como consequência deles.
Só venho relemebrar neste ponto de que muita gente diz que encapsulamento se resume a colocar getters e setters para os atributos. Isso não é encapsumento de verdade. Encapsulamento de verdade é fazer um objeto ser responsável pelo gerenciamento do seu estado interno. E quanto aos padrões de projeto, cada um deles se aplica em uma determinada situação. Aplicar um padrão de projeto em um lugar aonde ele não se aplica ou não deveria ser aplicado acaba criando gambiarras e por isso é importante entender não apenas como aplicá-los, mas também aonde e quando aplicá-los.
No mais, além de aprender padrões de projeto (soluções reutilizáveis que funcionam para problemas recorrentes), também é importante entender os anti-padrões (soluções ruins frequentemente utilizadas que não funcionam direito). Uma ótima referência (embora humorística) é essa: http://desciclo.pedia.ws/wiki/Gambi_Design_Patterns. Afinal, além de saber o que fazer, é preciso saber o que não fazer.
[quote=ingridfarabulini]
não se apegue muito aos códigos. Até entendo quando diz que aprender padrões e mais padrões vai ser prejudicial… mas ficar tentando entender códigos e mais códigos você acabaria caindo naquela frase mesmo que falou “padrão, cada um tem o seu”.[/quote]
Pra mim não faz sentido o que você falou.
[quote=victorwss]Todos os padrões de projeto (inclusive o MVC) tem a característica de criar soluções reutilizáveis para problemas recorrentes. Mantenha isso sempre em mente.
É importante também aprender princípios de orientação a objetos, que são a base para todos (ou quase todos) os padrões em POO: Encapsulamento, polimorfismo, alta coesão e baixo acoplamento. “Law of Demeter” também é uma importante consequência disso. Um projeto bem feito de verdade deve seguir estes princípios, e os padrões de projeto acabam surgindo mais ou menos como consequência deles.
(…)E quanto aos padrões de projeto, cada um deles se aplica em uma determinada situação. Aplicar um padrão de projeto em um lugar aonde ele não se aplica ou não deveria ser aplicado acaba criando gambiarras e por isso é importante entender não apenas como aplicá-los, mas também aonde e quando aplicá-los.[/quote]
victorwss, sábias palavras. Concordo 100%.
Olá… já escrevi o código daquilo que entendi até o momento.
:arrow: CAMADA APLICAÇÃO
// Esta classe principal está na Camada de Aplicação.
public class AgendaIngrid {
public static void main(String args[]) {
AgendaConfig conf = new AgendaConfig();
conf.config();
AgendaPresenter presenter = conf.getPresenter();
presenter.start();
}
} // Esta classe de configuração está na Camada de Aplicação.
public class AgendaConfig {
private AgendaPresenter presenter;
public void config() {
AgendaViewA view = new AgendaViewC();
AgendaModeloA model = new AgendaModelo();
this.presenter = new AgendaPresenter(model, view);
}
public AgendaPresenter getPresenter() {
return this.presenter;
}
} :arrow: CAMADA FUNCIONAL: ANDAR CLIENTE
// Esta classe é um dos 'n' inputs do Andar Cliente e é uma das 'n' possíveis telas que serão exibidas ao usuário.
// Também é um dos 'n' outputs deste andar e fará input em um dos 'n' inputs no andar Apresentação.
import javax.swing.*;
import java.awt.event.*;
public class AgendaViewC extends JFrame implements AgendaViewA {
private AgendaPresenter ap;
private JTextField nome, eMail, telefone;
private JButton bCadastrar;
public AgendaViewC() {
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 >>"));
bCadastrar.addActionListener(
new ActionListener() {
public void actionPerformed(ActionEvent ae) {
ap.cadastrarAgenda();
}
});
add(p);
setTitle("Agenda Ingrid vs1.1");
setSize(720,70);
setResizable(false);
setDefaultCloseOperation(EXIT_ON_CLOSE);
}
public void setPessoa(Pessoa p) {
this.nome.setText(p.getNome());
this.telefone.setText(p.getTelefone());
this.eMail.setText(p.getEMail());
}
public Pessoa getPessoa() {
Pessoa p = new Pessoa();
p.setNome(this.nome.getText());
p.setTelefone(this.telefone.getText());
p.setEMail(this.eMail.getText());
return p;
}
public void exibir() {
this.setVisible(true);
}
public void setPresenter(AgendaPresenter ap) {
this.ap = ap;
}
}:arrow: CAMADA FUNCIONAL: ANDAR APRESENTAÇÃO
// Esta interface é um dos 'n' inputs do Andar Apresentação.
// E neste caso especifico é uma das 'n' views ( V do MVP ) que estão presentes neste mesmo andar.
interface AgendaViewA {
public void exibir();
public Pessoa getPessoa();
public void setPessoa(Pessoa p);
public void setPresenter(AgendaPresenter ap);
} // Esta classe é um dos 'n' presenters ( P do MVP ) que estão presentes no Andar Apresentação.
public class AgendaPresenter {
private AgendaModeloA m;
private AgendaViewA v;
public AgendaPresenter(AgendaModeloA model, AgendaViewA view) {
this.m = model;
this.v = view;
m.addModeloListener(
new AgendaModeloListener() {
public void onAtualizar(AgendaModeloEvent me) {
v.setPessoa(me.getPessoa());
}
});
}
public void cadastrarAgenda() {
m.cadastrar(v.getPessoa());
}
public void start(){
v.setPresenter(this);
v.exibir();
}
} // Esta interface é um dos 'n' outputs do Andar Apresentação.
// E neste caso especifico é um dos 'n' models ( M do MVP ) que estão presentes neste mesmo andar.
interface AgendaModeloA {
public void cadastrar(Pessoa p);
public void addModeloListener(AgendaModeloListener l);
}// Esta classe é uma implementação de uma das 'n' interfaces do M do MVP ( Neste caso específico, de AgendaModeloA ).
// Também é um dos 'n' outputs deste andar e fará input em um dos 'n' inputs no andar Domínio.
import java.util.*;
import java.util.concurrent.*;
public class AgendaModelo implements AgendaModeloA {
private Pessoa p;
private final Set<AgendaModeloListener> modeloListeners = new CopyOnWriteArraySet<AgendaModeloListener>();
public void cadastrar(Pessoa p) {
this.p = p;
// Acessa a camada inferior de domínio...
this.fireOnAtualizar();
}
public void addModeloListener(AgendaModeloListener ml) {
this.modeloListeners.add(ml);
}
public void removeModeloListener(AgendaModeloListener ml) {
this.modeloListeners.remove(ml);
}
private void fireOnAtualizar() {
AgendaModeloEvent evento = new AgendaModeloEvent(p);
for (AgendaModeloListener ml : modeloListeners) {
ml.onAtualizar(evento);
}
}
} public interface AgendaModeloListener {
void onAtualizar(AgendaModeloEvent e);
} public class AgendaModeloEvent {
private Pessoa p;
public AgendaModeloEvent(Pessoa p) {
this.p = p;
}
public Pessoa getPessoa(){
return this.p;
}
} public class Pessoa {
private String nome, eMail, telefone;
public Pessoa() {
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;
}
}Vejam, eu tenho uma dúvida recorrente. Sei que algumas das pessoas que estão ajudando vão ficar muito nervosas com a minha pergunta mas preciso fazê-la:
O certo seria as ‘n’ classes do andar Cliente conhecer as classes de visão do andar Apresentação e não os seus presenters diferentemente de como está escrito no código acima?
Como exemplo, só reparar na classe AgendaViewC. Ela está trabalhando com o presenter da Apresentação. Isso é completamente errado não? :? Estou ficando maluca !!
O correto será a interface AgendaViewA ser implementada no andar Apresentação e aí sim o andar Cliente fará chamadas aos métodos desse objeto implementado lá na Apresentação certo?
Porque aí Cliente estaria falando com a visão do andar inferior e não com o miolo dele ( o presenter ). Tem que falar com o V, não com o P, no caso de uma implementação de MVP ocorrer dentro do andar Apresentação. Certa eu?
Estou tendo muita dificuldade em entender isso: as camadas devem ser isoladas não? É errado um andar superior implementar uma interface da camada inferior a não ser uma visão deste inferior?
Aí me desculpem muitooo pelo desconforto das minhas perguntas… eu sou muito leiga em arquitetura. Tenham paciência comigo, não desistam… 
Obrigada, ficarei aguardando… Até mais.
…apagando algumas mensagens: este tópico é total perda de tempo…
…apagando algumas mensagens: este tópico é total perda de tempo…
…apagando algumas mensagens: este tópico é total perda de tempo…
…apagando algumas mensagens: este tópico é total perda de tempo…
…apagando algumas mensagens: este tópico é total perda de tempo…
[quote=ceklock][quote=ingridfarabulini]
Percebi que você também é iniciante ( assim com eu ) em Java pelas suas postagens anteriores[/quote]
Iniciante em java? hahahhahahahahha!!! Sou experiente o suficiente se você quer saber. [/quote]
Realmente me desculpa, expressei mal minha visão de forma errada, estou errada. 
Não se preocupe em postar código, não perca o seu tempo com isso.
Obrigada por ajudar Até…
…apagando algumas mensagens: este tópico é total perda de tempo…
Ingrid , o seu código está mais que certo, para o propósito que o fez. Não mude nada, está bom assim.
Quanto aos TO/DTO vc usou sim. A classe pessoa é um TO (Transfer Object).
Errado. O que vc fez está correto é assim mesmo.
Imagine que vc implementava a interface AgendaViewA no andar de apresentação. Como vc teria acesso aos comandos do usuário ?
Sem linkar com a camada de cliente vc nunca teria acesso as esses comandos, mas sem eles, a apresentação é inutil.
Vc precisa linkar a interface da camada com o cliente.
Acho que o problema aqui é o seguinte, vc está pensando que a camada de baixo não pode invocar a camada de cima e por isso, implementar interfaces da camada de baixo na de cima seria algum tipo de violação, mas não é isso. O que está acontecendo aqui é que a interface AgendaViewA atual como um callback. A camada apresentação chama essa interface. E ela continua não sabendo que essas chamadas vão parar no cliente e é isso que é importante. A camada de apresentação não sabe quem implementa a interface e não lhe importa, é por isso que a interface pode ser implementada por outra camada (alias, essa é condição sin qua non para ter um bom desacoplamento).
Sim, mas o que singnifca isolar ? Esse é o ponto aqui. Vc acha que isolar é implementar em camadas diferentes, mas isso não é isolar. Isolar é que nenhuma das camadas sabe que realmente está falando com a outra.
“sabe” significa “depende de classes ou importação de classes da outra camada” ( interfaces pode, classes não). Ou seja, logicamente existe um corte limpo sobre o que é de quem, mas fisicamente, em algum ponto uma classe ou um cojunto delas é simultaneamente das duas camadas. Essas classes formam a “supreficie de contato”. Elas são agentes na fronteira. e na fronteira elas tem que saber que existem os dois lados. O ponto é que : apenas elas conhecem os dois lados. E isso é que é isolar. Se todas as classes de cada camada sabem que existem os dois lados, temos um problema.
Não ha como não ter classes na fronteira. O truque é as ter ( alto isolamento) e terem pouca responsabilidade (baixo acoplamento).
O problema aqui não é sobre patterns ou java. É sobre OO e o conceito de isolamento de camadas vs implementação de codigo.
Pense assim, o interreptor insola vc da rede eletrica, mas permite que vc controle se a luz está acesa ou não. Mas quando vc toca com o dedo no interruptor fisicamente falando vc está entrando em contacto fisico com o circuito eletrico. Então o interruptor a isola logicamente , mas na implementação não como o interruptor não contactar ao mesmo tempo o circuito electrico e o seu dedo.
[quote=sergiotaborda]Não ha como não ter classes na fronteira. O truque é as ter ( alto isolamento) e terem pouca responsabilidade (baixo acoplamento).
O problema aqui não é sobre patterns ou java. É sobre OO e o conceito de isolamento de camadas vs implementação de codigo.
[/quote]
Vocês podem isolar as classes por pacotes. As classes de um pacote que não devem ser vistas por outros pacotes não podem ser públicas. Um façade serviria para expor o que é útil para ser utilizado em outros pacotes.
[quote=sergiotaborda]Pense assim, o interreptor insola vc da rede eletrica, mas permite que vc controle se a luz está acesa ou não. Mas quando vc toca com o dedo no interruptor fisicamente falando vc está entrando em contacto fisico com o circuito eletrico. Então o interruptor a isola logicamente , mas na implementação não como o interruptor não contactar ao mesmo tempo o circuito electrico e o seu dedo.
[/quote]
Este conceito se chama Black Box (pelo menos acho que é isso que você estava querendo dizer):