Hum? Muitas vezes você não pode retornar um “double” simples e sim um Double (podendo este assumir o valor de null) porque o problema pede explicitamente isso.
E é por isso que em .NET existe o tipo “double?” (abreviatura de Nullable<System.Double> ) justamente para levar esse caso em conta.
Por exemplo, em uma planilha Excel você pode ter números faltando (nesse caso é o “null”) e números zero.
Na hora de calcular a média desses números, você ter algo que retorna 0 para indicar um número faltando é um erro. [/quote]
fico mt grato pela sua explanação.
é sério!
Estava lendo os posts, e qdo cheguei nesse “quoted”, me senti um pouco deprimido, pelo fato de ja ter usado a abordagem de retornar null, justamente pra não retornar um “falso Zero”.
mas logo recuperei minha auto estima.
e sobre a questão estética. acho q ternário ficou até bonitinho.[/quote]
Bom, vcs os dois podem se continuar enganando e afagando vosso ego achando que é certo que um numero possa ser null quando é usando em contas. Eu perfiro não cometer esse erro.
Existem várias opções para tratar isto. Desde usar default value até não usar Double e sim um Value Object proprio para tratar casos especiais. (Se o cara colocar NaN na importação, vc aceita? Não né ?)
Não existe essa de “falso zero” . Se o campo é esperado intervir em um calculo ele deve existir. Caso contrário um valor deve ser atribuido quando ele não existe ou não está disponivel. O fato do banco gravar null, não significa que a entidade tem que entender null quando fizer as contas (por isso o value object próprio tem vantagens porque vc pode condificar uma instancia no padrão NullObject e fazer com que as operações matemáticas saibam trabalhar com estte valor.
Portanto, o fato de usar Double porque a info vem do banco ou de outro sistema que permite nulls apenas porque double não aceita terceiro estado não é razão o bastante. Se vc criou o sistema, se vc definiu o campo, vc não deveria ter usado Double ou não deveria ter deixado ser null. E mais, em questões de dinheiro todo o mundo sabe ( ou deveria saber, afinal não estamos mais nos anos 80) que usar double/Double para representar dinheiro é fria. É por isso que existe o padrão Money.
Para quem ainda tem dúvidas, pesquise sobre Tiny Types e Strong Typing. É sempre melhor vc controlar objetos e não null (afinal é Orientação a Objetos , não Orientação a Referencias Nulas).
O ternário é um operação útil, mas cada vez que é usado tem algo errado no design. Foi citado o .NET, então vamos citar o Scala e o seu Optional. Repare-se que o conceito de “não tem valor” continua lá , mas sempre usando uma instancia de um objeto e nunca deixando a referencia vazia. Linguagens mais modernas como Kotlin vão mais longe proibindo qualquer uso de null. Porque NullPointerException é simplesmente a exceção mais lançada. E a maior parte das vezes por erro de design.
Se fosse algum outro valor que não fosse usando em calculos (mas vai dai provavelmente não seria Double) podemos até ser mais linientes, mas quando o campo é um dinheiro, ainda por cima um total ?! ora, isso é obviamente um erro de design. O uso da palavra “incompetência” é proposital para despertar este tipo de reação do GilsonNunes. Vamos deixar de passar a mão na cabeça e dizer que está certo porque a microsoft faz. Estamos em outro século. Está errado e é bom que todos saibam. Só assim poderão fazer melhor.