Vagando pela net, achei um artigo bem interessante de um tal de Allen Holub AQUI,
onde o autor mostra uma alternativa aos famigerados getter´s e setter´s que tanta gente detesta.
Apesar de eu ter achado uma boa solução pra matá-los :mrgreen: , tambem achei um pouco complexa. Gostaria de ter a opinião da galera sobre a alternativa usada pelo autor, e também, como é que vc´s tem feito para evitar o uso dos getter´s e setter´s.
cara, eu nao tenho absolutamente nada contra os getters e setters
Mas mesmo q eu tivesse, essa ideia de usar um monte de Interfaces e tal da muito trabalho…
Fora a parte do HTML, achei bonito. Mas realmente trabalhoso. Preferi o meu jeito fazendo uma gambiarrinha com reflection hehe
E maxguzenski, quando estiver envolvido num projeto médio/grande, vai ver que dói bastante colocar tudo nas actions, como o autor demonstra aqui:
value = amount.getValue();
currency = amount.getCurrency();
conversion = CurrencyTable.getConversionFactor( currency, USDOLLARS );
total += value * conversion;[ainda não li o artigo, o site aparece lento demais aqui :(]
O problema não é get/set, o problema é expôr desnecessariamente um atributo 
Eu gostei da idéia de deixar seus atributos e getters/setters como privado, e só expor a interface dométodo responsável por alguma ação.
hm, sera q o projeto q estou trabalhando a 2 anos pra uma multinacional , com uma equipe de 10 pessoas , utilizando Spring/Hibernate e Jboss é um projeto de medio/grande porte ?
E exatamente por isso, o projeto tem cerca de 50 tabelas, mais de 50 classes de hibernate… sem contar classes de view, controller , toneladas de DAO
me parece q essa ideia das Interfaces iria aumentar de forma desnecessária o trabalho para projetos grandes, pois nao iria diminuir a possibilidades de erro… no maximo ia ficar mais elefante (e atrazado).
max, isso é pequeno, na verdade pequeníssimo hehe temos dois projetos desse tamanho aqui. Se o cv aparecer, quem sabe ele fale do projeto com 20mbs de .java em que está trabalhando.
Concordo que o que o autor sugere é um pouco exagerado. Mas aprendi que colocar lógica de negócio fora dos objetos é uma grande cagada, obviamente, tudo tem exceções. No princípio não parece, mas depois vai doer, acredite 
Aidna não li tud, mas já vou pitacar:
Como java não tem selective export (falei sobre isso aqui outro dia), você pdoe sim utilizar interfaces para demarcar o que um cliente pdoe ver de uma classe, entretanto a abordagem dele acaba criando tantas interfaces distintas e em lugares tão exóticos que parece complicar as coisas muito mais.
20mb? Sao 150 :mrgreen:
Gostei dessa ideia mas pela integração da UI do que pela eliminação das getters e setters.
Dá para fazer binding de uma maneira bem interessante.
Agora o que eu não gosto dos getters e setters é somente a nomeclatura.
Em outras linguagens como PHP eu usava
definirXXX e obterXXX.
Podem achar que é uma frescura, mas se a classe está toda em portugues fica muito esquisito colocar coisas em ingles.
Esse negócio de get e set eu uso só por inércia como muita coisa do java.
como retornar collection generica.
eu acho melhor não expor a collection mas sim criar métodos de manipulação.
ex:
class Nota
{
private int codigo;
private Date data;
private List itens;
public void definirCodigo(int codigo) {}
public void definirData(int codigo) {}
public int obterCodigo() {}
public Date obterData() {}
public void adicionarItem(ItemNota item)
{
itens.add(item);
}
public ItemNota obterItem(int indice)
{
//
}
public int obterNumeroDeItens() {}
}Quando expondo um atributo, eu preferiria
class Teste{
int idade;
public int idade(){return idade;}
public void definirIdade(int idade){this.idade=idade;
}Na verdade, o setter tanto faz (ccom código em inglês eu usaria get), mas a query sendo apenas o nome do que se quer obter (não necessariamente o nome do atributo, você pdoe, por exemplo, calcular idade em runtime baseado na data de nascimento) é mais natural.
O que é melhor:
int idade= usuario.getIdade();ou
int idade = usuario.idade():? (nota: esqueça padronização aqui)
Ficou melhor ainda sem o obterXXX.
É verdade, fica mais intuitivo você ter funcionario.idade().
Eu acho que o pessoal do GUJ deveria fazer uma campanha.
“Vamos adotar padrões decentes !!!”.
O que complica é que em frameworks como hibernate, struts a gente fica dependente dos getters e setters.
Ou Nao ?
[quote=maxguzenski]hm, sera q o projeto q estou trabalhando a 2 anos pra uma multinacional , com uma equipe de 10 pessoas , utilizando Spring/Hibernate e Jboss é um projeto de medio/grande porte ?
E exatamente por isso, o projeto tem cerca de 50 tabelas, mais de 50 classes de hibernate… sem contar classes de view, controller , toneladas de DAO
me parece q essa ideia das Interfaces iria aumentar de forma desnecessária o trabalho para projetos grandes, pois nao iria diminuir a possibilidades de erro… no maximo ia ficar mais elefante (e atrazado).[/quote]
Garanto que muitas dessas classes poderiam ser jogadas fora. Quantas so de VO/DTO que nao fazem nada a nao ser um monte de get/set tem por ai?
]['s
[quote=pcalcado]
int idade= usuario.getIdade();ou
int idade = usuario.idade():? (nota: esqueça padronização aqui)[/quote]
Eu prefiro a segunda, mas uso a primeira pela padronizacao.
Pois é, apesard e mais natural, na verdade quando você trabalha com algo que outras pessoas precisam ler é melhor seguir padrões.
Nao eh soh importante seguir os padroes, como eh ESSENCIAL seguir a nomenclatura de getters e setters se vc for usar coisas como o java.beans.Introspector e afins (que eh o que o Hibernate, Struts, WebWork e amigos usam). A menos que voce esteja afim de testar os limites do codigo dos outros provendo BeanInfo…
Ninguém usa BeanInfo’s… N.I.N.G.U.E.M
Ou seja, ou segue a nomenclatura, ou tá perdido.
Esse é o principal impecilio para deixar de usar getters e setters.
Que Mer…
ressuscitando tópico…
Pessoal nosso amigo Sabella comenta:
existe um artigo do Calçado: http://fragmental.com.br/wiki/index.php?title=Fantoches, no qual ele diz:
se n me engano, o livro java efetivo tambem diz algo a respeito.
oque entendi disso tudo e que presensio é que a maioria dos sistemas possuem objetos apenas com seus dados e os getters e setters. Oque é “terrivel”, uma vez que pode-se mudar o estado de um objeto tornando-o inconsistente sem contar que toda a logica de negocios fica numa classe manipuladora desse objeto, logo a logica nao pode ser reaproveitada.
Postando na pratica:
ESTRUTURADO:
struct de luxo
public class Chamado {
private StatusChamado status;
private Calendar dataEncerramento;
//getters e setters
}classe de negocios
public class ChamadoBusiness {
public void encerrar(Chamado chamado) {
chamado.setStatus(StatusChamado.ENCERRADO);
chamado.setDataEncerramento(Calendar.getInstance());
}
}beleza, funciona, porem fica estruturado, sem contar que alguem em algum lugar do codigo pode fazer:
chamado.setStatus(StatusChamado.ENCERRADO);e esquecer de setar a data criando assim um objeto num estado invalido.
o certo seria colocar o comportamento dentro do proprio chamado e nao fazer o setter:
public class Chamado {
private StatusChamado status;
private Calendar dataEncerramento;
private void encerra() {
this.status = StatusChamado.ENCERRADO;
this.dataEncerramento(Calendar.getInstance());
}
// getters
}Prezados amigos, entendi certo ou “viajei na maionese” ? rsrsrs
Outra pergunta, o que fazer quando frameworks exigem os getters e setters ?
grande abrasssssss
Também sou da mesma opnião de que o autor cria interfaces desnecessárias. Image isso em uma sistema de 100 tabelas no banco e consequentemente teremos 100 classes. Usando a abordagem do autor não teria como você usar o framework por exemplo que depende dos getters e setters, ou qualquer outro que dependa.
Acho o seguinte que devemos ter estes atributos somente onde é necessário