Desculpe duplicar o tópico mas estou realmente interessado nisso:
Acho que eu to lesado hoje, não to notando a duplicação. A classe Usuario criptografa a senha, e a classe CaixaEletronico autentica(verificando se ela é válida ou não).
[quote=pcalcado]Sem um exemplo completo fica difícil, Felipe.
Realment eos livros vão te ensinar a modelar os aspectos do seu problema como objetos, você vai ter usuários, cartões de crédito, vendas, estoques, grupos… tudo como objetos de negócio.
A camada de apresentação vai receber estímulos dos usuários e vai passar estes para a APIda camada de negócios, que vai fazer as operações nos objetos de acordo com o estímulo. Se for necessário, essa alteraçãod eve disparar uma interação com a camada de persistência, para que atualize o SGBD/XML/PQP de acordo com o estado atual dos objetos.
[/quote]
É mais ou menos nesse modo que trabalho hj (mais pra menos)…
Acho que depois disso tudo fica uma pergunta ainda:
Como tratar as respostas vindas da camada de persistência? Como fazer para que elas “voltem” para a camada de apresentação, sendo que o Fabio já falou que meus if’s estão loooonge do ideal??? Gerando exceções???
[size=7]eu juro que já to acabano com a perguntação[/size]
Ok, acho que foi ume xemplo mal formulado, ams vamsot entar prosseguir.
Primeiro, acho que estamo enxergando diferente: imagine usuário como um cadastro de usuário, estamos imaginando igual?
Vamos lá, eu quero usar o caixa eletrônico, eu me cadastro no banco XYZ.
A rotina de cadstro vai e criptografa minha senha.
Eu vou usar o caixa eletrônico, o caixa quer saber se a minha senha confere, ele dá um get na senha do usuário (recebendo a versão criptografada) e criptografa a senha que eu informei apra poder comparar.
Você tem duas classes fazendo a mesma coisa (não necessariamente código repetido, mas funcionaldiade repetida. Elas podem usar uma classe utilitária para criptografar, mas aidna assim estão fazendo a mesma coisa em dois lugares diferentes).
Respostas “certas”?
Transofrme os registros em objetos novamente e os jogue na camada de negócios.
Respostas erradas?
Isso é quebra de cotnrato, em Java é tratado com exceções.
É, acho que estamos enxergando diferentemente:
Eu imaginei o Usuario criptografar a senha, e o Caixa Eletronico apenas autenticar, verificar se ela é realmente válida. Porém o Caixa Eletronico receberia uma senha, independente de ela estar criptografada ou não(tudo que ele sabe é que é uma senha, não sabe se esta criptografada, embaralhada, etc).
Agora voltando ao ponto inicial, conclui-se então que neste caso getters e setters não têm sentido nenhum.
Na maiorira das vezes não.
Os beans t~em sentido dentro do cotnexto deles, que não é o suado hoje.
[quote=pcalcado][quote=fzampa]
Como tratar as respostas vindas da camada de persistência? Como fazer para que elas “voltem” para a camada de apresentação, sendo que o Fabio já falou que meus if’s estão loooonge do ideal??? Gerando exceções???
[/quote]
Respostas “certas”?
Transofrme os registros em objetos novamente e os jogue na camada de negócios.
Respostas erradas?
Isso é quebra de cotnrato, em Java é tratado com exceções.
[/quote]
Ótimo! Obrigado mesmo…
Acho que por hj tá bom, vou dar uma lida em padrões, agora já tenho uma idéia de “o que fazer com padrões”.
Obs.: Bom, eu cheguei nessa necessidade pq estava vendo que aquilo que o Fernando Anselmo ensinou nao era a melhor opção. Será se todo mundo que trabalha com java sem conhecer os Design Patterns (seja web, local, celular…) grava as informações no banco na mesma classe que exibe os dados??? Tudo a lá Pascal?? É isso que estou percebendo que vc fala que uma grande parte do pessoal trabalha em java como se fosse proceduralmente???
Obs2.: Depois eu volto com mais duvidas… e mais conteúdo tb. Falous…
[quote=pcalcado]Respostas erradas?
Isso é quebra de cotnrato, em Java é tratado com exceções.
[/quote]
Completando. Por exemplo deu um erro na camada de persistencia, la no DAO. Imagine que voce tentou inserir um usuario repedido e o teu banco de dados deu erro de PK.
Quem deve saber que deu erro? A tua camada de negocio certo?
Então propage a excecao até ela e trate de maneira conveniente, colocando mensagens de erro que “traduzam” o que ocorreu. Fazendo isso é so enviar esse retorno (com erro ) à tua camada de apresentacao fazendo ela mostrar a mensagem de erro.
Agora como fazer isso?? Tem N artigos, tutoriais na web sobre isso, com framework sem framework, em app web ou mesmo desktop. Sabendo o conceito e o que deve ocorrer vai ser bem mais tranquilo pra ti entender os artigos tutoriais.
Uma dica, baixe projetos open souce e de uma olhada no codigo para aprender. O GUJ2 ou o ONLite (que estamos fazendo pro JavaFree) é uma pedida para ver como frameworks sao aplicados. O JForum é uma boa pedida pra ver como fazer sem framewok algum. eu mesmo ja mexi demais nos codigos do Rafael para estudo, e ver como outras pessoas implementam as coisas. 
]['s
O nome da classe realmente foi mal colocado:
mude para :
class Autenticacao
{
}
Essa classe não define uma entidade mas uma operação ou um conjunto de operações.
E login nesse sentido que eu coloquei é um substantivo e não um verbo,
pode dar perfeitamente um nome para uma classe.
Não se pode comparar isso com VB. Não é OO puro, mas também não é algo horrivel…
Felipe, Design Patterns são consequências de uma modelagem OO. Se você estudar OO, ao ler um livro sobre padrões, as coisas vão fazer muito mais sentido do que simplesmente tentar aplicar aquelas soluções no seu projeto. Se seus objetos não foram bem pensados e não são inteligentes o bastante, não há Design Pattern que vai salvar o seu projeto hehe
E falo isso pois estou passando exatamente por esse momento, e sofrendo com o código já escrito usando “mvc” 
Tem umt exto ótimo do Meyer sobre “achar substantivos que são classes”, no primeiro liro da lista do outro tópico (eu li ontem 
) dê uma olahda se possível. basicamente, isso não é a melhor nem a úncia maneira de se descobrir uma classe em um sistema.
Chegamos á uma subjetividade muito grande neste exemplo. Se autenticação é uma classe ou não depende do contexto do sistema.
jprogrammer, como falei: se você quer questionar a utilidade ou a super-estimaçãod e OO, não é o tópico certo, simplesmente porque eu estou tentando te msotrar uma maneira que eu considero legald e fazer OO, mas se você não acredita em OO, não tem o que te msotrar (pelo menos não por enquanto )
[quote=fzampa]Será se todo mundo que trabalha com java sem conhecer os Design Patterns (seja web, local, celular…) grava as informações no banco na mesma classe que exibe os dados??? Tudo a lá Pascal?? É isso que estou percebendo que vc fala que uma grande parte do pessoal trabalha em java como se fosse proceduralmente???
[/quote]
viu pq eu falei do livro?
Sim vejo que você é um entusiasta do OO.
E vejo que você tem profundo conhecimento também.
Eu gosto muito do OO, ele torna a programação muito mais inteligente e auto-documentavel.
Não estou sendo contra, apenas quero resaltar que as vezes temos que dar uma quebradinha nos paradigmas.
Podemos sim fazer isso sem perder a elegancia.
jprogrammer
Você está confundindo layers com tiers.
Um layer é uma separação lógica de partes do teu programa, um layer só deve falar com os layers ajdacentes a ele.
Um tier é uma camada física do seu sistema.
Ou seja, enquanto a separação entre layers é tenue e normalmente depende dos desenvolvedores definirem as fronteiras, já com tiers basta procupar por um cabo de rede interconectando eles.
Layers e tiers servem propósitos diferentes, BEM diferentes. Layers existem para melhorar o organização do software e facilitar o desenvolvimento. Tiers existem para segmentar dados e processos, quase sempre para atingir maior performance.
Existem boas formas para se escreve o software que faz a comunicação inter-tier e inter-layer.
Comunicação inter-tier costuma ser feita usando DTOs, que é uma representação compacta e sem comportamento dos teus objetos. Eles servem apenas para esse propósito.
Objetos do mesmo tier devem existir no mesmo layer pois eles costumam promover uma rica troca de mensagens entre sí, oque inviabilizaria seu uso entre tiers.
Por último vou falar sobre essa tua paranoia infundada sobre sistemas distribuidos.
É extremamente raro encontrar um sistema distribuido que seja uma federação de nós, o modelo dominante é master/workers com alocação dinâmica de trabalho.
No universo J2EE você vai encontrar quase nenhum caso de SD federado, é mais provavel com JINI - e eu nunca ouvi falar de JINI no mundo real.
Um exemplo de SD federado que você vai encontrar provavelmente é caching distribuido coerente, e isso 99,9998% das pessoas usa algo pronto e não escreve o seu.
Dentro do modelo master/workers essa tua preocupação de muitos objetos remotos é exagerada, quando existe é por incompetencia dos arquitetos que não souberam planejar.
[quote=LIPE]Felipe, Design Patterns são consequências de uma modelagem OO. Se você estudar OO, ao ler um livro sobre padrões, as coisas vão fazer muito mais sentido do que simplesmente tentar aplicar aquelas soluções no seu projeto. Se seus objetos não foram bem pensados e não são inteligentes o bastante, não há Design Pattern que vai salvar o seu projeto hehe
E falo isso pois estou passando exatamente por esse momento, e sofrendo com o código já escrito usando “mvc” :|[/quote]
Aí, Lipe, OO basicamente eu sei, tb nao sou assim tão cru… na verdade eu achava que sabia mais um pouquinho :mrgreen:
O projeto que estou foi assim, digamos, bem estruturado. Não foi melhor pq eu nao sabia dos padroes e tals… mas agora já está simples de entender os design patterns.
Obrigado!
Pergunta fatal e inevitável: Qual um bom livro sobre o assunto? Core patterns?
louds gostei da sua explicação e de sua visão.
Isso ampliou mais minha visão.
Você teria a “conexão” das tiers sem compromentimento das layers.
Um recurso poderia ser o DTO.
Mas isso não poderia gerar redundancias ?
O client iria conversar com o DTO. O DTO passa os dados para o serviço.
O serviço passa para as classes de domínio que fazem as operações.
então a gente teria:
class UsuarioDTO
{
private String nome;
private Strnig senha;
//getters and setters
}
// pode ser qualquer servico EJB, RMI…
class ServicoAutenticacao
{
public void autenticar(UsuarioDTO usuarioDTO)
{
Usuario usuario = new Usuario();
usuario.setNome(usuarioDTO.getNome())
usuario.setSenha(usuarioDTO.getSenha())
usuario.autenticar();
}
}
class Usuario
{
private String nome;
private Strnig senha;
//getters and setters
public void autenticar()
{
//
}
}
E qual seria uma solução??
[quote=renato3110]
E qual seria uma solução??[/quote]
Delegue essa responsabilidade a uma classe.
[code]~
class Usuario{
private Senha senha;
public boolean verificarSenha(Senha s){
return criptografar(s).equals(senha)
}
public void defineSenha(Senha s){
senha = criptografar(s).equals(s)
}
public Senha criptografar(Senha s){
…
}
}
[/code]
Shoes, mas se a classe usuário for remota, o cliente teria que criptografar a senha antes de enviar pela rede. E então?
Tu tá andando muito com o jprogrammer 
Leia o psot do louds.
Isso é coisa de infra-estrutura