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.
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.
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^^
[quote=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^^[/quote]
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.
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…
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
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: