Enfim, qual é uma boa alternativa que vocês utilizam pra acabar com um monte de ifs pra verificar se os atributos de um objeto qualquer estão nulos ou não?
crie um método que retorne “” se o resultado for null, ou o valor se caso contrário (isso é parecido com o tal do COALESCE do PL/SQL do Oracle)
String campo1 = coalesce (get1());
[/quote]
thingol, a necessidade é basicamente evitar o tenebroso NullPointerException na manipulação deste objeto, ou seja, se o retorno do get1() não for nulo, eu uso ele, senão, passo pra frente. Como nem todos os campos são String, não dá pra retornar “” pra todo mundo, e mesmo usando um método pra retornar “” eu ainda teria que colocar um monte de ifs, o que você acha?
public class ObjectUtils{
public boolean isNull(Object obj){
return obj == null;
}
public boolean isNotNull(Object obj){
return obj != null;
}
// Outros métodos de verificação
}
Você gostaria que, se algum dos métodos voltasse null, em vez de ficar dando um monte de null pointer exception, você simplesmente obtivesse o valor “null” para sobrenome. Isso acho que até existe para algumas linguagens de script (como o Groovy) mas infelizmente não no Java.
Foi proposto para o Java 7 um operador novo (chamado “elvis” - provavelmente devido à frase “Elvis não morreu” - esse operador vem do Groovy), que ajuda nesse encadeamento. Você poderia fazer então:
Uma das coisas que eu penso é que utilizar valores como “null” é de fato, erros de codificação.
Por exemplo, um NPE será lançado somente em situações onde houve erros de código. Simples assim.
Verificações de nulabilidade é aumentar a possiblidade de se ter problemas, a não ser que você esteja criando um sistema de alta performance e quer ver o GC trabalhando pra caramba.
A minha sugestão é que evite de todas as maneiras que haja valores nulos, na camada de nível mais alto. Por exemplo, sabemos que há situações em que tu não recebe os parâmetros corretos de forms, aí eles virão nulos, mas quando tu tiver que passar algo pra camadas mais baixas (como façade, negócios, persistencia e assim por diante) passe alguma coisa “não-nula”, algo com “estado” ou na melhor das hipóteses, um “enum”.
desculpa se eu não conseguir explicar direito, qualquer coisa eu tento explicar mais tarde denovo ;p
Você gostaria que, se algum dos métodos voltasse null, em vez de ficar dando um monte de null pointer exception, você simplesmente obtivesse o valor “null” para sobrenome. Isso acho que até existe para algumas linguagens de script (como o Groovy) mas infelizmente não no Java.
Foi proposto para o Java 7 um operador novo (chamado “elvis” - provavelmente devido à frase “Elvis não morreu” - esse operador vem do Groovy), que ajuda nesse encadeamento. Você poderia fazer então:
É exatamente isso thingol, é a idéia de encadear getters mesmo.
Tomara que implementem isso no Java 7, mas por enquanto, é colocar um monte de IFs mesmo.
[quote=Leozin]Uma das coisas que eu penso é que utilizar valores como “null” é de fato, erros de codificação.
Por exemplo, um NPE será lançado somente em situações onde houve erros de código. Simples assim.
Verificações de nulabilidade é aumentar a possiblidade de se ter problemas, a não ser que você esteja criando um sistema de alta performance e quer ver o GC trabalhando pra caramba.
A minha sugestão é que evite de todas as maneiras que haja valores nulos, na camada de nível mais alto. Por exemplo, sabemos que há situações em que tu não recebe os parâmetros corretos de forms, aí eles virão nulos, mas quando tu tiver que passar algo pra camadas mais baixas (como façade, negócios, persistencia e assim por diante) passe alguma coisa “não-nula”, algo com “estado” ou na melhor das hipóteses, um “enum”.
desculpa se eu não conseguir explicar direito, qualquer coisa eu tento explicar mais tarde denovo ;p[/quote]
Leozin, o que acontece é que, por boas práticas, todos os métodos públicos devem validar os seus argumentos antes de manipulá-los, bem no esquema do serviço mesmo, você implementa um método pra outra pessoa usar, logo, essa outra pessoa pode te passar algo nulo. Então, para o erro não acontecer no seu método (serviço) você faz essa validação.
Bom, eu sei que nao é exatamente o que vc esta procurando, mas pelo menos economiza linhas de código…
por exemplo, temos um objeto Pessoa p; e um atributo nome do tipo String…
*EDIT e um campo sobreNome tbem neh
na hora de setar o nome em um campo na tela, ao invés de fazer:
String nomeCompleto = "";
if (p.getNome() != null) {
nomeCompleto = p.getNome();
if (p.getSobreNome() != null) {
nomeCompleto += " " + p.getSobreNome();
}
}
jTextField1.setText(nomeCompleto);
eu costumo usar o operador condicional ternário
mas mesmo assim, com dois atributos, a linha ja ficou ruim pra ler, mais eu uso bastante isso, nao só com validações de null, mas tbem com objetos booleanos…
Leozin, o que acontece é que, por boas práticas, todos os métodos públicos devem validar os seus argumentos antes de manipulá-los, bem no esquema do serviço mesmo, você implementa um método pra outra pessoa usar, logo, essa outra pessoa pode te passar algo nulo. Então, para o erro não acontecer no seu método (serviço) você faz essa validação.
Att.[/quote]
Concordo que seja ideal validar os parâmetros, mas validar parâmetros nulos eu acho que é um saco hehehe. Validar o estado do objeto tudo bem, mas acho que validar se o mesmo é nulo ou não, era algo que deveria ser evitado ao máximo, como por exemplo, evitando possibilidades de descer o nível de objetos nulos entre as camadas.