bem vc resumiu o que eu quiz passar em minha ultima postgem em poucas palavras…
[quote=ceklock][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]
Olá… 
Lá no meu código tenho duas camadas ( andares ): Cliente e Apresentação.
Como você faria para isolar essas camadas em pacotes? Onde aplicaria os Façades?
Até +…
[quote=ceklock][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):
[/quote]
Já lí sobre isso mas em Engenharia de Software na área de testes de software. Caixa Preta é para testar se não há códigos sem uso no algoritmo e testar fluxos, algo do gênero.
Acho que aqui houve sim um erro de interpretação em relação ao que o Sergio falou… enfim… Até mais! 
voltando ao assunto… isolar significa que a camada n não conhece a camada n-1 a unica ligação entre elas e que a camada n requisita um serviço para a camada n-1. Lembrando que este serviço pode ser retornar um bean por exemplo… a camada n não conhece a camada n-1 apenas sabe que esta tem o serviço a lhe oferecer… mas não sabe como este serviço e implemetado… ou seja so lhe prove uma interface para o serviço utilizado… se usar uma facade por exemplo ambas camadas n e n-1 não conheceram nem a interface e serviço entre elas apenas conheceram o facade e o facade conhecera as interfaces de cmunicação entre elas…
por exemplo se tivermos um sistema de 2 camadas por exemplo…
onde teremos uma camada para a visão e outra para a persistencia
como exemplo temos 3 classes: PessoaView, PessoaCore e Facade
e temos o metodo salvar o nosso amigo PessoaView recebe uma requisição de um usuario para salvar um objeto pessoa, ao receber esta requisição como o pobre coitado do PessoaView não sabe salvar o objeto ele chama o Facade e pede para ele salvar o objeto pessoa… o Facade não sabe fazer isto mas conhece quem sabe o PessoaCore, este pede para o PessoaCore salvar o objeto e o PessoaCore o salva no banco…
mais tarde o SEO não quer mais que as pessoas sejam salvas no banco apartir de agora as pessoas serao salvas em xmls… e este ordena que altere as 500 telas do sisteminha que usam o objeto pessoa e faça isto para ontem… o unico trabalho que teremos e alterar o metodo salvar de nosso PessoaCore para ao invez de salvar no banco salvar em arquivos xml… não vamos precisar alterar nada referente a nossa camada de visao pois esta desconhece mesmo a existencia do PessoaCore…
O mesmo se aplica a visão… se mais tarde o CEO quiser que o sistema seja em desktop, em web ou mesmo em console :shock:
não teremos problema com o backend… apenas com o front…
para devemos ser bem organizado nos pacotes e com nomeclaturas… por exemplo:
com.meusistema.pessoa.view
PessoaView.java
com.meusistema.facade
Facade.java
com.meusistema.pessoa.core
PessoaCore.java
Particularmente gosto de utilizar 3 camadas nos sistemas que desenvolvo, Web (Apresentação), Negócio e DAO (Ou integração, ou como queiram).
Até hoje não tive a necessidade de utilizar mais que isso pois desenvolvemos aqui na empresa sistemas com uma finalidade específica então varia pouca coisa entre os projetos, mas é sempre bom estar antenado nessas discussões enriquecedoras que rolam aqui no GUJ.
Eu acho que todos que participam dessas discussões, até mesmo os que atuam apenas como leitores, devem ser parabenizados pois isso demonstra busca de conhecimento. Eu fico pasmo com a quantidade de “analistas” e “programadores” que tem no mercado que não estudam porra nenhuma, quando precisam de alguma coisa dão uma googlada e colam o primeiro código que vêem pela frente no projeto que estão atuando.
Olá Sergio
Sim entendi a explicação. Realmente você ‘captou’ bem aquilo que tentei perguntar. Minha dúvida era mesmo se a implementação de uma interface da camada inferior poderia ser realizada na camada superior. E entendi o porque do uso de interfaces. Obrigada pelo elogio do código… :oops:
Algumas perguntas básicas:
- Como a visão do andar Cliente ( AgendaViewC ) possui um AgendaPresenter que não é uma interface e sim uma classe… seria interessante AgendaPresenter ser uma interface?
- TO pertence a qual camada ou andar já que ele está sendo utilizado por dois andares, até este momento? ( Cliente e Apresentação )
- O andar Apresentação não deve conhecer nada do Swing ( import’s ou componentes ) porque se um dia eu mudar a visão no andar Cliente ( Ex: trocar do Swing para o JFace ou do Swing para o SWT :lol: hihihi… fanfarrona
) eu não vou precisar mudar nada no andar de Apresentação, como está no código que fiz aqui. - Neste mesmo link acima, perceba que AgendaViewC tem uma dependencia de AgendaPresenter e este se auto-repassa ( this, linha 25 ) para a AgendaViewC através do método para que este possa usá-lo. É certo isso ou correto seria fazer isso no AgendaConfig?
Algumas perguntas ‘procurando cabelo em ovo’:
4) Um andar possui outros andares dentro dele? ( Ex: Andar Cliente tem outros três, quatro ou ‘n’ andares? ou ‘DAO pertence ao andar Integração do andar Domínio?’)
5) Na verdade, o MVP é formado por ‘interface de visão + interface do presenter + interface do modelo’ mas no Andar de Apresentação ( que é onde as três interfaces devem estar ) só serão implementados o ‘P’ e o ‘M’, visto que o ‘V’ quem implementará será sempre o andar Cliente? Ou estou enganada? Como já foi dito o andar de cima não é obrigado a implementar nada do andar de baixo mas se isso não acontecer, também como já foi dito, a apresentação seria inútil. Ou seja, podemos definir o MVP como:
‘V’ está implementado no andar Cliente.
‘P’ e ‘M’ estão implementados no andar Apresentação.
Ahh e isso que é chamado de callback? Entendi direito?
Obrigada Sergio… muito obrigada pela paciência e pelo respeito que trata as minhas perguntas e a mim mesma, é simplesmente lindo e admirável…
Espero que suas respostas sejam sempre respeitadas igualmente pelos colegas. :-o
Vou aguardar, até + moço…
Olá Luis…
[quote=luistiagos]voltando ao assunto… isolar significa que a camada n não conhece a camada n-1 a unica ligação entre elas e que a camada n requisita um serviço para a camada n-1. Lembrando que este serviço pode ser retornar um bean por exemplo… a camada n não conhece a camada n-1 apenas sabe que esta tem o serviço a lhe oferecer… mas não sabe como este serviço e implemetado… ou seja so lhe prove uma interface para o serviço utilizado… se usar uma facade por exemplo ambas camadas n e n-1 não conheceram nem a interface e serviço entre elas apenas conheceram o facade e o facade conhecera as interfaces de cmunicação entre elas…
por exemplo se tivermos um sistema de 2 camadas por exemplo…
onde teremos uma camada para a visão e outra para a persistencia
como exemplo temos 3 classes: PessoaView, PessoaCore e Facade
e temos o metodo salvar o nosso amigo PessoaView recebe uma requisição de um usuario para salvar um objeto pessoa, ao receber esta requisição como o pobre coitado do PessoaView não sabe salvar o objeto ele chama o Facade e pede para ele salvar o objeto pessoa… o Facade não sabe fazer isto mas conhece quem sabe o PessoaCore, este pede para o PessoaCore salvar o objeto e o PessoaCore o salva no banco…
mais tarde o SEO não quer mais que as pessoas sejam salvas no banco apartir de agora as pessoas serao salvas em xmls… e este ordena que altere as 500 telas do sisteminha que usam o objeto pessoa e faça isto para ontem… o unico trabalho que teremos e alterar o metodo salvar de nosso PessoaCore para ao invez de salvar no banco salvar em arquivos xml… não vamos precisar alterar nada referente a nossa camada de visao pois esta desconhece mesmo a existencia do PessoaCore…
O mesmo se aplica a visão… se mais tarde o CEO quiser que o sistema seja em desktop, em web ou mesmo em console :shock:
não teremos problema com o backend… apenas com o front…
[/quote]
Interessante… e me parece muito com o que está explicando o Sergio. :idea:
Por exemplo você citou os andares visão/cliente e a persistência. Se colocar mais um andar, o de apresentação, entre os dois andares existentes e nesse andar usar o pattern MVP faremos exatamente aquilo que explicou como Façade, estou errada? :roll: Veja o código nesta postagem. ( só que no link temos os andares Cliente e Apresentação, o próximo seria o de domínio )
Estou certa que o conceito mostrado por você está correto. Nesse caso, o andar Integração também seria um Façade entre Domínio e Recursos, errei novamente? :oops:
O André Fonseca no ínico explicou para usar Façade, mas sem a explicação do Sergio não havia entendido o porque de Façades… 
Uma perguntinha: Bean == TO ?
Até +… Obrigada.
Em Tese tudo deve começar por ser uma interface. Isso permite um desing melhor. Na prática isso nem sempre é necessário. contudo, de vc quiser aumentar o desacoplamento e ter classes mais simples de testar vc usa uma interface. Assim, quando vc estiver testando, vc pode passar uma implementação “falsa” apenas para teste.
Portanto, seria interessante se o seu sistema tivesse intenção profissional. Para um sistema faz de conta não precisa. Contudo, se seu objetivo é simular que está fazendo um projeto profissional, então sim. Seria quase que obrigatório devido ao desacoplamento.
Eu já respondi isso em algum lugar. Não pertence em nenhum dos dois. Os objetos que transitam andares pertencem na camada de aplicação.
Contudo, podemos pensar neles como pertencendo ao dominio e erradiando para os outros andares. (normalmente eles ficam no pacote algumacoisa.domain)
Exatamente.
Seria melhor fazer no AgendaConfig todas as configurações de dependencia.
Não. Como diria o Spock “isso é ilógico”.
Dentro de um andar podes ter camadas de api, mas não outros andares.
Antes do MVP serem objetos eles são responsabilidades e contratos. O como são implementados é um detalhes do processo de construir o software e não pertence no padrão em si. Não ha problema que o contrato seja implementado em outra camada desde que seja por um objeto de fronteira ( se for por outro tipo de objeto é um erro conceptual). O mecanismo de callback ou de “mexer sem saber onde” é muito importante porque diminui o acoplamento.
Olá… quero agradecer a todos que me ajudaram neste tópico
E agradecer ao Sergio Taborda por todo esforço que destinou a ele também em tentar entender o melhor possível minhas perguntas para responde-las também o melhor possível… 
Eu estou fazendo uma revisão geral de tudo que aprendi quanto as camadas ( andares ) de Visualização e Apresentação.
Porém esses dias lendo um artigo publicado em uma revista fiquei assustada com uma afirmação… :shock:
A afirmação é a seguinte: “A camada de Apresentação é responsável pela interação entre sistema e usuário. Como exemplo dos componentes dessa camada, podemos citar: menus de seleção, telas para entrada e apresentação de dados, caixas de diálogo e componentes que indicam a ocorrência de algum processamento, como cursores de mouse em forma de empulheta e barras indicadoras de progresso” … “existem duas bibliotecas de componentes gráficos que disputam a preferência dos desenvolvedores de sistemas desktop: SWT e Swing” …
A perguntinha é simples rapazes e meninas: Vocês também se assustaram com a afirmação que a descrição acima é da camada de Apresentação? :shock:
Porque até agora meus estudos indicam que isso é da camada de Visualização e esta sim, poderá conhecer as API SWT ou Swing, como desejar. Estou certa?
Obrigada
…
Então nos meus estudos aprendi que a camada/andar de visualização/cliente é quem recebe o input do usuário e onde também é mostrado ao usuário o resultado de suas ações. Esse usuário pode ser humano ou não. Já a camanda/andar de apresentação é quem torna os comandos do usuário coerentes com o propósito do sistema, ou seja, é ela quem toma a decisão do que acontecerá de fato. É nessa idéia que deposito minha confiança. Veja que ‘contraste’ existe naquilo dito na revista e no que está sendo dito agora… Não é assustador? :shock: Chega a causar pesadelos !! 
É muito óbvio que o que está escrito no artigo da revista se refere a Camada/Andar de Cliente/Visualização.
E realmente é a teoria até este momento mais realista e convencedora. É o conceito mostrado, e pacientemente explicado, pelo Sergio a quem gostaria de agradecer mais uma vez. É nisso que acredito até provarem o contrário. Ainda gostaria de saber a opinião dos demais… :idea:
Até +… Obrigada
Então nos meus estudos aprendi que a camada/andar de visualização/cliente é quem recebe o input do usuário e onde também é mostrado ao usuário o resultado de suas ações. Esse usuário pode ser humano ou não. Já a camanda/andar de apresentação é quem torna os comandos do usuário coerentes com o propósito do sistema, ou seja, é ela quem toma a decisão do que acontecerá de fato. É nessa idéia que deposito minha confiança. Veja que ‘contraste’ existe naquilo dito na revista e no que está sendo dito agora… Não é assustador? :shock: Chega a causar pesadelos !! É muito óbvio que o que está escrito no artigo da revista se refere a Camada/Andar de Cliente/Visualização.
E realmente é a teoria até este momento mais realista e convencedora. É o conceito mostrado, e pacientemente explicado, pelo Sergio a quem gostaria de agradecer mais uma vez. É nisso que acredito até provarem o contrário. Ainda gostaria de saber a opinião dos demais… :idea:
Até +… Obrigada :D[/quote]
Ok. Cada um com suas teorias. Eu estou me retirando deste tópico. Boa sorte a quem fica.
ué, pelo padão MVC Model ,View, Control. a visão éo mesmo que apresentacao usa awt ou swing para fazer as telas de cada funcionalidade do programa.se vc tem um funcionalidade manter Cliente vai ter uma visão para o cadastro do cliente, nome cpf etc…
que é uma telinha para os dados do cliente ser persistido em algum lugar , cada tela de cada funcionalidade tem um Control que controla os eventos de clicar botao arrastar etc…, quando determinado evento ocorrer um objeto listener da sua tela JButton ou etc escuta que ocorrer algum evento nele e transfere a execucao pro controle fazer algo, eu acho q apresentacao é a Visao msm das 3 camadas ou no caso 4 se for usar persistencia
[quote=ingridfarabulini]Olá… quero agradecer a todos que me ajudaram neste tópico
E agradecer ao Sergio Taborda por todo esforço que destinou a ele também em tentar entender o melhor possível minhas perguntas para responde-las também o melhor possível…
Eu estou fazendo uma revisão geral de tudo que aprendi quanto as camadas ( andares ) de Visualização e Apresentação.
Porém esses dias lendo um artigo publicado em uma revista fiquei assustada com uma afirmação… :shock:
A afirmação é a seguinte: “A camada de Apresentação é responsável pela interação entre sistema e usuário. Como exemplo dos componentes dessa camada, podemos citar: menus de seleção, telas para entrada e apresentação de dados, caixas de diálogo e componentes que indicam a ocorrência de algum processamento, como cursores de mouse em forma de empulheta e barras indicadoras de progresso” … “existem duas bibliotecas de componentes gráficos que disputam a preferência dos desenvolvedores de sistemas desktop: SWT e Swing” …
A perguntinha é simples rapazes e meninas: Vocês também se assustaram com a afirmação que a descrição acima é da camada de Apresentação? :shock:
Porque até agora meus estudos indicam que isso é da camada de Visualização e esta sim, poderá conhecer as API SWT ou Swing, como desejar. Estou certa?
Obrigada :D[/quote]
Pra mim, acho que o mais certo a se dizer é : depende do ponto de vista. O Sergio, por exemplo, é extremamente detalhista com tudo. Isso faz com que ele veja diferenças entre camada de apresentação e de visualização. (o que, a certo ponto, é correto, dada a explicação no tópico).
No entanto, a maioria das pessoas não se atém a esse tipo de detalhe e, portanto, camada de visualização == camada de apresentação para essas pessoas (e, confesso, para mim mesmo não há muita diferença, porque os sistemas que desenvolvo profissionalmente têm camadas de serviços e ponto. Tanto o usuário quanto outros sistemas devem interagir com essa camada de serviços.).
Então, não precisa se espantar com esse artigo, porque provavelmente ele estava apenas se referindo ao V do MVC - e não se atendo a nomenclaturas de andares, camadas, etc.
[]´s
[quote=bdias1990]ué, pelo padão MVC Model ,View, Control. a visão éo mesmo que apresentacao usa awt ou swing para fazer as telas de cada funcionalidade do programa.se vc tem um funcionalidade manter Cliente vai ter uma visão para o cadastro do cliente, nome cpf etc…
que é uma telinha para os dados do cliente ser persistido em algum lugar , cada tela de cada funcionalidade tem um Control que controla os eventos de clicar botao arrastar etc…, quando determinado evento ocorrer um objeto listener da sua tela JButton ou etc escuta que ocorrer algum evento nele e transfere a execucao pro controle fazer algo, eu acho q apresentacao é a Visao msm das 3 camadas ou no caso 4 se for usar persistencia[/quote]
Olá… Então tudo isso citado acima, na minha opinião, está na Camada/Andar de Visualização/Cliente. Quando esse Listener do JButton recebe o evento, ele acessa a Camada/Andar de Apresentação que é quem vai tornar esse evento em algo coerente ao sistema, como exemplo: presenter.Cadastrar(). Até porque se um dia precisar trocar a Visualização atual (pode ser de SWT para SWING) não precisaria mexer na Apresentação.
Obrigada pela sua opinião
Ela é importante para todos. Até +…
[quote=asaudate]Pra mim, acho que o mais certo a se dizer é : depende do ponto de vista. O Sergio, por exemplo, é extremamente detalhista com tudo. Isso faz com que ele veja diferenças entre camada de apresentação e de visualização. (o que, a certo ponto, é correto, dada a explicação no tópico).
No entanto, a maioria das pessoas não se atém a esse tipo de detalhe e, portanto, camada de visualização == camada de apresentação para essas pessoas (e, confesso, para mim mesmo não há muita diferença, porque os sistemas que desenvolvo profissionalmente têm camadas de serviços e ponto. Tanto o usuário quanto outros sistemas devem interagir com essa camada de serviços.).
Então, não precisa se espantar com esse artigo, porque provavelmente ele estava apenas se referindo ao V do MVC - e não se atendo a nomenclaturas de andares, camadas, etc.[/quote]
Olá… não entendi muito bem essa Camada de Serviços… Não existe uma UI para o usuário? :roll:
Poderia explicar melhor? Obrigada
============================================================================
Camada de Aplicação --> Usuario
Camada de Apresentação --> Representação da informação (codificação e decodificação)
Camada de Sessão --> Multiplexação da Transmissão (portas e socktes)
Camada de Transporte --> Garantia de entrega e sequencia
Camada de Rede --> Roteamento e envio do datagrama
Camada de Enlace --> Enquadramento e envio de loop-local
Camada Fisica --> Hardware
Ps: Cada camada opera, realiza mais funçoes, mas isso ta bom para um resumão.
Eis a minha contribuição ingridfarabulini
Deixo esta informação adicional para vc ingrid.Não é bem o que vc pediu, mas OK
Olá pessoal…
Dei uma lida rápida sobre os posts e acho que a colega está bem servida de explicações…
Vou colocar aqui apenas algumas observações sobre o que eu penso de todas essas camadas…
Desenvolvo sistemas web, e como nosso colega Daniel mencionou, 3 camadas são suficientes para a maioria das situações em que trabalho (web, serviço e dao)
Na minha camada web, tenho ainda um controller (uma classe Controller) e a visão (JSP) (Provavelmente o colega também terá)
Minha camada de serviços (Service), geralmente contém regras de negócios, e não integram com camadas externas como banco de dados, ou servlets, http.
Minha camada DAO fará acesso ao banco de dados, então conterá código de persistencia e integração com JDBC, etc.
Ainda tenho as entidades que são qualquer coisa entre os DTO, VO, TO… (uma classe com atributos, getters e setters apenas, que mapeio em tabelas do banco de dados)
Essas entidades trafegam em todas as camandas.
Uma dica simples para você observar sobre sua arquitetura, é verificar os imports que você está usando na sua classe.
Se numa classe de apresentação você está dando import de java.sql, está errado.
Se numa classe de persistencia ou negócios você está dando import de javax.swing também está errado.
O import não é uma medida perfeita de separação de camandas mas já dá alguma diretiva básica.
Com o tempo e experiencia você vai começar a separar também os pacotes da sua própria aplicação.
Cada vez mais refinando o código e melhorando a arquitetura.
Sobre os design patterns, as 3 diretivas básicas são:
1 - Favorecer a composição ao invés da herança
2 - Programe para interfaces
3 - Alta coesão e baixo acoplamento
Você pode começar com a diretiva 3, que significa: Mantenha códigos relacionados próximos (alta coesão), ou seja, se tem uma função de excluir e outra de incluir um funcionário, elas devem estar próximas. Na mesma classe por exemplo. Faça sua classe conhecer o mínimo possível de outras classes (baixo acoplamento), siga a dica dos imports, quanto menos melhor. E também quanto menos variados (menos pacotes diferentes) melhor.
Espero ter adicionado algo útil a discussão…
Até mais
Olá… na verdade essas camadas do título é referente a camadas lógicas ( andares ) de um sistema. Mas acabou sendo interessante porque nessas camadas de rede, visto que analizou a citação do artigo que fala de camadas lógicas, você discorda e também acredita que o que nele está escrito pertence a Camada/Andar de Visualização. Isso é exatamente o que aprendi e fico feliz que é assim também em uma estrutura de redes.
Muito obrigada
Ficarei aguardando por mais opiniões…
[quote=rogelgarcia]Olá pessoal…
Dei uma lida rápida sobre os posts e acho que a colega está bem servida de explicações…
Vou colocar aqui apenas algumas observações sobre o que eu penso de todas essas camadas…[/quote]
Olá… obrigada pelas dicas Rogel e pela sua opinião ao todo.
Eu, ao contrário de ti, sempre programei Desktop mas sem seguir nenhum padrão. Chega uma hora que você acaba percebendo que há uma necessidade de começar a programar as coisas de uma forma universal ou próximo daquilo que as outras pessoas conseguem entender. Por isso quando aprendo uma coisa e leio outra fico indignada… faço o esforço possível para aprender aquilo que é certo e de repente me deparo com um artigo em uma boa revista dizendo outra coisa e até mesmo invalidando aquilo que foi aprendido. Fico confusa… :? Mas o caso do artigo é um dos casos de exemplo à parte… O que gostaria de saber da comunidade que utiliza ou conhece essas duas camadas/andares de Visualização e Apresentação é realmente quais são as suas reais diferenças. Muitos dizem que não há diferenças, são iguais. Outros poucos dizem que sim, existem diferenças sim. E alguns dizem: Não existe uma e outra, as duas é uma :shock:
Ao meu entender, sim, existe diferença e a principal delas é justamente deixar a Visualização completamente independente da Apresentação, como no caso de substituir uma SWT por SWING ou JavaFX. Até mesmo como citou o Rogel em relação aos imports. A apresentação não deve ter nenhum import do Swing, ou melhor, nada. Mas a visualização pode ter e muito é para isso que essa camada/andar serve.
Mas precisaria muito da opinião de vocês. O conceito foi a mim explicado pelo Sergio Taborda e essa idéia é até este momento a melhor, a certa… mas se existe algum problema/desentendimento com relação a ela preciso conhecer… porque as pessoas teimam em rejeitar tanto esse conceito? O que há de errado nele?
Obrigada
Ficarei aguardando mais opiniões