[Resolvido]Getters e Setters com Validações

1 de setembro de 2011 7 respostas

danielpump 1 de setembro de 2011

Bom Dia, eu estava fazendo um trabalhinho de cadastros simples na facul, e comecei a me irritar com um pequeno incomodo
tipo toda vez, que vocÊ vai setar o valor e por exemplo a chave é int, tinha que ficar toda hora convertendo de String para int, e como encheu o saco eu criei tipo…

public int getUsuarioId(){
return usuarioId;
}

public void setUsuarioId(int usuarioId){
this.usuarioId = usuarioId;
}

public String getUsuarioIdString(){
return Itenger.toString(usuarioId);
}

public void setUsuarioIdString(String usuarioId){
if(usuarioId == null || usuarioId.equals("")){
return;
}
this.usuarioId = Itenger.parseInt(usuarioId);
}

Então gostaria de saber a opinião de vocês sobre esta forma de trabalho, pois para mim ficou muito simples, tanto que passei a utilizar no projeto, só tenho que ver se meu prof aprova…rsrs, mas isto se aplica a vários outros tipo, principalmente os de datas, ficou mais facil e não preciso toda hora no meio da aplicação ficar convertendo os tipo.

Mas então o que acham?

7 Respostas

nel 1 de set. de 2011

Oi!

A validação em um getter e/ou setter eu acho interessante, até porque é um dos motivos de se utilizar o encapsulamento.
Mas se teus getters e/ou setters precisam fazer esse tipo de conversão, acho errado.
Na minha opinião eles já deveriam ser do tipo String e/ou int, pois não vejo o sentido de no setter ser um int e no getter uma String.

Usa-se sempre o mesmo tipo para o setter e o getter de um determinado atributo e não da forma como você fez.
Mesmo que dê trabalho, defina como String também o setter ou como int o getter e faça a conversão quando for necessário.

Abraços.

danielpump 1 de set. de 2011

Então mas no casa é por causa da entrada de dados, por exemplo o que retorna de um JTextField é uma String certo!
A não ser que tenho como retornar uma valor int e eu não saiba^^, sei-lá sobrescrevendo um método talvez e criando o retorno int, mas achei melhor fazer desse jeito, principalmente por causa dos campos de datas que eu ficava sempre instanciando a mascara no meio da aplicação dai achei melhor fazer isso lá, dai já comecei a validar os nulos la tambem, já que vai ter que passar por lá mesmo, até agora não tive problemas, mas como não achei ninguem comentando sobre isso, quis expor a idéia e ver as opiniões^^

nel 1 de set. de 2011

danielpump:
Então mas no casa é por causa da entrada de dados, por exemplo o que retorna de um JTextField é uma String certo!
A não ser que tenho como retornar uma valor int e eu não saiba^^, sei-lá sobrescrevendo um método talvez e criando o retorno int, mas achei melhor fazer desse jeito, principalmente por causa dos campos de datas que eu ficava sempre instanciando a mascara no meio da aplicação dai achei melhor fazer isso lá, dai já comecei a validar os nulos la tambem, já que vai ter que passar por lá mesmo, até agora não tive problemas, mas como não achei ninguem comentando sobre isso, quis expor a idéia e ver as opiniões^^

Talvez o getText() seja uma forma de sobrescrita, o que eu não aconselho.
Os sistemas Swing que eu vi (poucos, trabalhei/trabalho muito com Web) é normal fazer o parser do valor String para o que você precisa.
Continue executando a validação de nulo ou vazio, é interessante, mas não faça o mesmo atributo retornar um tipo no getter e setar outro no setter, não faz sentido. É como se o seu atributo não tivesse um tipo definido.

Abraços.

adriano_si 1 de set. de 2011

Cara, se for o caso, cria uma camada aí no meio pra fazer esse tipo de validação/conversão.

Porém para simplificar, eu criaria um Util pra fazer isso, lá você poderia colocar inclusive regras de conversão, como por exemplo, pra qual formato de datas você quer transformar sua String, tratar NumberFormatExceptions em um único lugar, enfim…

Abs [] e sucesso.

danielpump 1 de set. de 2011

rsrsr… eu tambem tinha pensado isso, principalmente por causa do getter que eu tbm realmente tinha achado estranho, mas como facilitou minha vida né…rsrsrs

mas blz… por isso vim atrás de opiniões…vlw^^

adriano_si 1 de set. de 2011

A grande questão é justamente que o Seu Bean deve ficar livre de validações de tela. Se você setou seu atributo como int, seus Getters e Setters devem refletir isso.

Pense se mais tarde você quiser criar um Bean a partir de algum outro lugar setando valores padrão ?? Vai fazer isso setando Strings só para poder passar na validação ??? Vai sobrecarregar os Getters e Setters ???

Mas cara, uma coisa que aprendi com o tempo, e inclusive falamos sobre isso aqui no GUJ outro dia, se essa aplicação for muito simples e tiveres certeza que os Beans vão sempre receber somente valores da tela, porque não simplificar ???

Só não torne isso uma prática, pois algum dia em algum SIstema Enterprise, se commitares um Bean assim, o programador que der manutenção, vai te amaldiçoar até morrer… heueheueheuheueheueheuehue

Abs []

[EDIT] - claro que quando dei a idéia de simplificar ignorei 2 coisas: 1 - Seu sistema crescer / 2 - O aprendizado correto. Como é um Sistema de Facul, o ideal é aprender da forma certa, então não simlifique, ignore minha sandice… rsrsrsrs :lol:

danielpump 1 de set. de 2011

KKK… Vlw mesmo pelas dicas. principalmente esta do Util, tenho uma aqui que já faz umas coisas, só tenho que implementar mais ela^^

Mas Vlw mesmo se quiserem mudar por Off-Topic acho que é mais apropriado que no básico, em todo caso, vou colocar resolvido

VLW^^MSM Nel e Adriano

Criado 1 de setembro de 2011

Ultima resposta 1 de set. de 2011

Respostas 7

Participantes 3

7 Respostas

Topicos relacionados