Não. Ele não precisa. Nós fazemos isso porque estamos usando MVP na apresentação, mas a camada de cima não precisa implementar coisas da camada de baixo.
A função desse andar é cuidar da experiência do usuário, da ergonomia, facilidade de uso, respondabilidade e de certa forma a “imagem” do produto.
Ele é composto de componentes gráficos ( por isso que swing é a ferramenta para ele). Ele deve oferecer a melhor forma de input e output possivel.
Sim.
Oi Sergio, obrigada por continuar a me ajudar 
Você entendeu bem a minha pergunta e respondeu ela melhor ainda. Mas ainda preciso saber se entendi corretamente o ‘output’ do andar Cliente.
No andar Cliente, falando de um sistema simples quanto ao de uma Agenda, muito provavelmente teriamos ‘n’ telas/interfaces/objetos que fariam o input neste andar. Seja esse input vindo de um usuário humano ao clicar em um botão ou de um outro nodo ( andar Integração ) querendo se comunicar com este nodo ( andar Cliente ) ou ‘n’ outras possibilidades. Muito bem. Vamos assumir que o Swing é o exemplo mais puro que podemos encontrar de compnentes com uma boa implementação do pattern MVC. Sendo assim, cada componente do Swing é um ( C )ontroller. Ex:
// Andar Cliente, neste momento só tem esta classe que é o input deste andar.
public class Tela extends JFrame {
public Tela() {
JPanel painel = new JPanel();
JButton botao = new JButton("OK");
botao.setEnable(false);
painel.add(botao);
add(painel);
setVisible(true);
}
}
// Camada Aplicação
public class TelaOK {
public static void main(String args[]) {
Tela t = new Tela();
}
}Veja: JFrame, JPanel e JButton são controladores. Até este momento temos um único ‘input’ no sistema que é justamente essa classe Tela recheada de componentes Swing. Perceba que no JButton não existe nenhum Listener adicionado ouvindo os eventos de negócios ( não sei se esse é o nome certo, mas acho que deu para entender 
) lançados pelo modelo do botão. A visão muda normalmente ao clicar/soltar o botão, muito provavelmente porque a visão recebe o evento do ‘click’ que é canalizado ao controlador que chama o método responsável no modelo que se altera e lança um evento para a visão via Observer ( não sei se é exatamente isso pois alguns dizem que sim, Swing implementa MVC e outros dizem que não, que Swing implementa outra coisa mas não vem ao caso agora ).
Mas precisamos de um ‘output’ para o andar Cliente certo? Então qual a melhor forma de fazer isso? Horas, vamos começar implementando um Listener nesse JButton que passará agora a escutar os eventos de negócios. Ex:
// Andar Cliente, neste momento só tem esta classe que é o input deste andar.
public class Tela extends JFrame {
public Tela() {
JPanel painel = new JPanel();
JButton botao = new JButton("OK");
botao.setEnable(false);
botao.addActionListener(
new ActionListener {
public void actionPerformed(ActionEvent e) {
// PONTO que captura o evento de negócio lançado pelo JButton.
}
});
painel.add(botao);
add(painel);
setVisible(true);
}
}
// Camada Aplicação
public class TelaOK {
public static void main(String args[]) {
Tela t = new Tela();
}
}Pronto! Temos um dos ‘n pontos’ que a classe Tela poderia conter que é a linha 11 do código acima. Agora, é neste PONTO que surge a pergunta:
Porque estou perguntando isso? Para chegar a conclusão da primeira etapa de uma boa estruturação dos Andares Cliente e Apresentação e a forma como eles se comunicam.
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?
Obrigada
Tópico graande Ingrid, não tenho tempo para ler tudo(tenho uma deadline para terça…), vou deixar que o Sérgio lhe explique os detalhes de implementação.
Sobre esse trecho:
[quote]
Tenho que discordar. O objetivo de estudar design patterns não é ser um bom programador. é ser um bom designer. E se o design é bom, a programação é trivial. Acontece que muita gente acha que qualquer tipo de design vale. Que se muda depois, KISS essa palermice toda… na realidade não é trivial conseguir um bom design e se a pessoa almeja um dia ser um bom designer, precisa sim aprender patterns. [/quote]
Concordo em parte, Sérgio.O fundamental de saber design patterns, é saber que cada um tem seus usos(e limitações), e saber aonde aplicar cada um.Se vc realmente sabe a maioria deles, vc acaba sendo mais do que um bom designer, vc se torna um bom arquiteto de software. Design patterns, são, antes de tudo, soluções para problemas recorrentes encontrados em desenvolvimento de software.Vou lhe contar um caso real: num projeto que eu fiz, o cara(novato), só queria saber aonde se colocava o Singleton e o Facade, pouco se lixando para a implementação.Era um sistema prevalente, e o Singleton até servia, mas quando eu vi o código… OMFG! :shock: Era uma classe de 7mil linhas(o que chamo de GOD MODE anti-pattern) que era irrefatorável, tamanho a quantidade de coisa que ela tinha/fazia.Claro, nessa época eu ainda vi coisas, como a tradução de Singleton para Solteirão(!!!) devido a instância única…
++!
Acho mais importante definir formas de trabalhar primeiro, do que se embrenhar pelo mundo dos padrões de projeto.
Destacando novamente isso:
[quote]
Que se muda depois, KISS essa palermice toda… na realidade não é trivial conseguir um bom design e se a pessoa almeja um dia ser um bom designer, precisa sim aprender patterns. [/quote]
Não há dúvidas quanto a isso Sérgio, mas acho que ANTES dos patterns, o desenvolvedor tem que focar na lógica(sem ela ele não anda), para não virar um mero componentizador(o programador “Kit5”, acho que vc sabe a que me refiro…), e ao que vc citou acima, que são formas de trabalhar.Meu medo de explicar padrões a iniciantes, é que quando aprendem um, eles analisam tudo que cai na mão deles TENTANDO encaixar o que foi aprendido, e não analisar o problema e ver se uma solução por padrão SE ENCAIXA no problema.
…apagando algumas mensagens: este tópico é total perda de tempo…
…apagando algumas mensagens: este tópico é total perda de tempo…
Olá…
[quote=ceklock][quote=ingridfarabulini]Oi Sergio, obrigada por continuar a me ajudar
[/quote]
É uma das três principais partes que constitui uma arquitetura de software: Plataformas, Andares e Qualidades. ( link )
Defina ‘Andares’ como camadas lógicas. Cliente, Apresentação, Domínio, Integração e Recursos. Você deve conhecer isso como camadas, mas para não existir ambiguidade definimos como andares, Ok? Até +…
O que é “Andar” ? Você está projetando um prédio?
[/quote]
Andares é uma das três partes que constitui uma arquitetura de software: Plataformas, Andares e Qualidades. ( link )
Defina ‘Andares’ como camadas lógicas com cuidado: Cliente, Apresentação, Domínio, Integração e Recursos. Você deve conhecer como ‘Camadas’ mas como a palavra é ambigua definimos particularmente como andares. ( Esse detalhe você obtém maiores informações na segunda postagem desse tópico 
)
Obrigada Continuarei aguardando pela resposta desta postagem. Até +…
…apagando algumas mensagens: este tópico é total perda de tempo…
Sim.
Sim.
Sim
Já lhe tinha dito antes que não ha mais padrões especificos para isso. Apenas boa OO e o uso das API.
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.
O problema é então com o programador e a pedagogia , não com os padrões ou o fato de que sim, é preciso saber padrões.
Claro que “saber padrões” não é decorar os nomes e implementações exemplo. É realmente saber onde se aplicam e como. Saber implementar o padrão para o caso em mãos e saber quais variantes usar. É como usar um parafuso, o conceito é simples, mas a aplicabilidade se aprende com experiencia.
Como já expliquei antes, andar (do inglês story) é o nome que se dá à camada funcional da aplicação.
é um conceito de arquitetura, e sim é baseado na metáfora do prédio.
O nome Andar é usado para diferenciar de Nodo, Plataforma e Camada (camada é o nome mais abstrato que inclui andar, plataforma. Pesquise pelo padrão Layer). Principalmente para diferenciar camada de código (conjunto de classes , API) de camada de funcionalidade (que é o andar, que é uma orquestração de camadas de codigo)
Concordo plenamente. Usar padrões em excesso é extremamente prejudicial. Se não forem usados de maneira correta, o que vai acontecer é que ao invés de simplificar as coisas, você vai complicar.
[quote=sergiotaborda]
O nome Andar é usado para diferenciar de Nodo, Plataforma e Camada (camada é o nome mais abstrato que inclui andar, plataforma. Pesquise pelo padrão Layer). Principalmente para diferenciar camada de código (conjunto de classes , API) de camada de funcionalidade (que é o andar, que é uma orquestração de camadas de codigo)[/quote]
Provavelmente o padrão layer é pouquíssimo usado em projetos comuns. Eu tenho um livro de padrões de projeto e este padrão não é citado (o livro só cita os padrões mais populares).
Acho que o que vocês precisam é do MVC (Model, View, Controller) ou do Modelo em Três Camadas (Apresentação, Negócio, Dados). Querer usar patterns exóticos é pedir pra complicar tudo ao invés de simplificar. Padrões de projeto só fazem sentido se vão simplificar o projeto.
Concordo plenamente. Usar padrões em excesso é extremamente prejudicial. Se não forem usados de maneira correta, o que vai acontecer é que ao invés de simplificar as coisas, você vai complicar.
[/quote]
Não existe tal coisa como usar padrões em excesso. Se vc usa é porque vc precisa. Toda a API java é feita usando padrões e não foram demais (aliás foram de menos).
Não podemos julgar o uso ou não de padrões por aquilo que os iniciantes ou os inconpetentes fazem. Se o cara insiste em colocar aquilo que ele chama de “singleton” no projeto quando na realidade aquilo é apenas uma variável global, que culpa tem padrão singleton do uso incorreto? Que culpa têm os livros e que culpa têm os defensores do uso de padrões ? Nenhuma, excepto não terem explicado melhor. Mas mesmo quando bem explicado existe muita gente que não entende.
Quando eu comecei a programar java eu usava principios como SoC, encapsulamento, restrição de visibilidade, e outros… eu chegava no mesmo tipo de objeto que os padrões chegam, mas levava mais tempo. quando comecei a estudar padrões ganhei muito tempo. Hoje eu não penso em SoC e restrição de visibilidade quando quero fazer um esquema produtor-consumir, eu penso no padrão.
Padrões são feito para serem uma linguagem, uma melhora da comunicação. Ninguem é culpado se as pessoas não aprendem direito ( poderiamos dizer o mesmo da matemática ou da uml).
Ou vc usa um padrão ou vc não usa. Não tem essa de usar errado. Se está errado, e aquele padrão não se aplica alí, então isso não é usar o padrão. Usar um alicate para martelar não é usar um alicate.
Padrões devem ser aprendidos. Não é simples e não é rápido e nem todos têm capacidade para os entender, mas é uma necessidade em POO tal como saber matemática… (ups!..pensando bem tem muita gente que tb não sabe matemática…)
[quote=ceklock][quote=sergiotaborda]
O nome Andar é usado para diferenciar de Nodo, Plataforma e Camada (camada é o nome mais abstrato que inclui andar, plataforma. Pesquise pelo padrão Layer). Principalmente para diferenciar camada de código (conjunto de classes , API) de camada de funcionalidade (que é o andar, que é uma orquestração de camadas de codigo)[/quote]
Provavelmente o padrão layer é pouquíssimo usado em projetos comuns. Eu tenho um livro de padrões de projeto e este padrão não é citado (o livro só cita os padrões mais populares).
[/quote]
hummm… obviamente vc não sabe do que está falando. Provavelmente seu livro só fala dos padrões GoF ou dos padrões JEE. Existem muitos mais e muitos bastante uteis como Money e Ratio que vc não encontra nesses livros.
O “Modelo em Três Camadas” que citou é baseado no padrão Layer (three layers model)
Primeiro vc tem que conhecer os padrões que existem para depois estabelecer o que é exótico. Padrões de projeto sempre fazem sentido quando se aplicam. Não ha qualquer proveito em vc identificar o uso de um padrão e resolver não o usar.
Listeners são Models? Sinto muito, mas isso está errado! Todos os Listeners no MVC fazem parte da camada de Controle. Portanto o que ela falou está correto. A camada de controle © é a responsável por se comunicar com outras camadas.
M = Modelo (dados) - Exemplo no Swing: JTable tem um TableModel, que é responsável por gerenciar os dados da tabela. http://java.sun.com/javase/6/docs/api/javax/swing/JTable.html#getModel()
V = View (visualização, interface gráfica) - Exemplo no Swing: a interface gráfica da JTable.
C = Control (controle) - Camada que é responsável por verificar o Model e atualizar a View. Esta camada implementa o necessário para verificar se houveram mudanças nos dados e notificar a View para fazer alterações na visualização. Para isso são usados Listeners (eventos).
[quote=sergiotaborda][quote=ceklock][quote=sergiotaborda]
O nome Andar é usado para diferenciar de Nodo, Plataforma e Camada (camada é o nome mais abstrato que inclui andar, plataforma. Pesquise pelo padrão Layer). Principalmente para diferenciar camada de código (conjunto de classes , API) de camada de funcionalidade (que é o andar, que é uma orquestração de camadas de codigo)[/quote]
Provavelmente o padrão layer é pouquíssimo usado em projetos comuns. Eu tenho um livro de padrões de projeto e este padrão não é citado (o livro só cita os padrões mais populares).
[/quote]
hummm… obviamente vc não sabe do que está falando. Provavelmente seu livro só fala dos padrões GoF ou dos padrões JEE. Existem muitos mais e muitos bastante uteis como Money e Ratio que vc não encontra nesses livros.
O “Modelo em Três Camadas” que citou é baseado no padrão Layer (three layers model)
Primeiro vc tem que conhecer os padrões que existem para depois estabelecer o que é exótico. Padrões de projeto sempre fazem sentido quando se aplicam. Não ha qualquer proveito em vc identificar o uso de um padrão e resolver não o usar. [/quote]
Concordo 100% com o que foi falado nesse artigo:
http://parand.com/say/index.php/2005/07/18/i-hate-patterns/
Eu gosto de Design Patters. Mas quando alguém fica querendo aplicar Patterns em tudo, até aonde não precisa, isso é ruim. Aumenta a complexidade do código.
Vou citar um trecho do artigo:
[quote]Let me give you an example. Here?s the real world:
A senior developer, with 2 developers reporting to him, designed and implemented a subsystem. The need arose for what seemed to be a minor modification, and the developer responded with an estimate of two weeks. We were puzzled ? the change had every appearance of being simple. I?d have thought less than a day.
So we dug into the implementation. The developer presented the design of the subsystem. He had used EJBs along with the (name withheld to protect the innocent) pattern. The design hung together fairly well. But there was one glaring problem:
The entire subsystem could?ve been implemented with a fraction of the complexity by using a simple servlet connecting to JDBC. If you wanted to be fancy you could?ve used some abstraction of the database. That?s it. Really quite simple.
We gently pressed the developer on his design choices and why he seemingly favored the complex over the simple in almost every instance. He responded with the usual list of suspects: transactions, scalability, maintainability, ease of understanding.
Good list. Here?s the problem: we didn?t need transactions. Scalability doesn?t hold up: look at the highest scaling systems and you?ll see they?re not EJBs. In any case, servlets would?ve scaled just fine for our purposes. Maintainability and ease of understanding are easy to gauge: it?s easier to understand and maintain less lines of code. Less lines of code good, more lines bad.
Then we looked at the actual code. Good Lord. Copy and paste of major pieces into a several files. Justification? Horrible misuse of the poor, innocent factory pattern. Lines of code? Many. Many. Innocent patterns slaughtered everywhere.
We actually spent quite a bit of time with the developer, attempting to reform him. He was a good, smart guy, worth saving. Unfortunately we were unsuccessful, primarily because he sincerely believed he was right ? he was using EJBs and patterns. How could the simple, lowly servlet be a better path?
At the end one of our other developers rewrote the entire subsystem in his spare time in far less than two weeks. Lines of code? Something like 1/5th to 1/10th of the original. Faster. Understandable. Simple. The original developer moved on to create many many lines of code for some other company.[/quote]
Existem tantos padrões no mundo que é meio sem sentido chamar alguns de padrões.
Pra mim padrão é o que é mais usado.
Mas como diria alguém que não lembro o nome: “Padrão, cada um tem o seu” :lol:
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…
Concordo plenamente. Usar padrões em excesso é extremamente prejudicial. Se não forem usados de maneira correta, o que vai acontecer é que ao invés de simplificar as coisas, você vai complicar.
[/quote]
Não existe tal coisa como usar padrões em excesso. Se vc usa é porque vc precisa. Toda a API java é feita usando padrões e não foram demais (aliás foram de menos).
Não podemos julgar o uso ou não de padrões por aquilo que os iniciantes ou os inconpetentes fazem. Se o cara insiste em colocar aquilo que ele chama de “singleton” no projeto quando na realidade aquilo é apenas uma variável global, que culpa tem padrão singleton do uso incorreto? Que culpa têm os livros e que culpa têm os defensores do uso de padrões ? Nenhuma, excepto não terem explicado melhor. Mas mesmo quando bem explicado existe muita gente que não entende.
Quando eu comecei a programar java eu usava principios como SoC, encapsulamento, restrição de visibilidade, e outros… eu chegava no mesmo tipo de objeto que os padrões chegam, mas levava mais tempo. quando comecei a estudar padrões ganhei muito tempo. Hoje eu não penso em SoC e restrição de visibilidade quando quero fazer um esquema produtor-consumir, eu penso no padrão.
Padrões são feito para serem uma linguagem, uma melhora da comunicação. Ninguem é culpado se as pessoas não aprendem direito ( poderiamos dizer o mesmo da matemática ou da uml).
Ou vc usa um padrão ou vc não usa. Não tem essa de usar errado. Se está errado, e aquele padrão não se aplica alí, então isso não é usar o padrão. Usar um alicate para martelar não é usar um alicate.
Padrões devem ser aprendidos. Não é simples e não é rápido e nem todos têm capacidade para os entender, mas é uma necessidade em POO tal como saber matemática… (ups!..pensando bem tem muita gente que tb não sabe matemática…)[/quote]
Concordo com o sergio… não se pode culpar os padrões pelas mas utilizações dos mesmos… eles foram feitos para serem usados para solucionar problemas… se alguem usa-os de forma incorreta gerando problemas invez de soluções a culpa não é do padrão e sim de que o utilizou de forma inadequada…
[quote=luistiagos]
Concordo com o sergio… não se pode culpar os padrões pelas mas utilizações dos mesmos… eles foram feitos para serem usados para solucionar problemas… se alguem usa-os de forma incorreta gerando problemas invez de soluções a culpa não é do padrão e sim de que o utilizou de forma inadequada…[/quote]
Mas isso é óbvio… :roll: