Como não usar o Optional do Java
Por muito tempo que trabalhei com Java eu me conformei com a possibilidade de um NullPointerExceptionser um perigo iminente no código. Sempre à espreita, podendo aparecer em qualquer lugar a qualquer momento. Os nulls, indo e vindo no código, praticamente me diziam “Em algum momento você vai esquecer de me tratar!”, não havendo uma possibilidade de ter controle sobre eles sem apelar para uma programação defensiva, algo que costuma maltratar o código.
Muitos vêem o null com naturalidade no mundo da programação. Embora seja um ponto de vista polêmico, o próprio criador da “referência nula”, Tony Hoare, se arrepende de sua criatura:
This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Esta opinião parece ser compartilhada pela comunidade de desenvolvimento. Boa parte das linguagens novas não têm o conceito de referência nula, preferindo representar que uma informação pode não existir com o operador Élvis (?) ou mesmo com tipos maybe, optional, option, etc.
No mundo Java, embora algumas bibliotecas já oferecessem uma possibilidade para tratar isto há muito tempo, a adoção desta prática só se popularizou quando o próprio Java forneceu uma alternativa para evitar os nulls no código, com a introdução do Optional no Java 8.
Porém, ainda assim, é comum a existência de dúvidas na forma de utilizar o Optional corretamente. Só o fato de usar Optional não faz com que você esteja fazendo o uso correto do mesmo.
A seguir, vou apresentar um erro clássico no uso do Optional.
Optional como parâmetro
O conceito e vantagem de retornar Optional de um método ao invés de null é fácil de explicar. Ao receber uma informação opcional, você sempre verifica se ela realmente existe e obtém a informação. Simples.
Porém, é comum os desenvolvedores passarem o Optional como parâmetro de um método ou construtor, delegando a decisão de o que fazer com o Optional para um outro método. Esta é uma prática não recomendada devido às desvantagens envolvidas. Mas quais seriam elas?
Tomemos como exemplo o seguinte código:
A princípio, parece inofensivo. Porém, quem chama este método precisaria fazer:
Convenhamos: mesmo com apenas um parâmetro opcional, não é um código de leitura tão simples. Um método com mais parâmetros opcionais fica pior ainda de ler:
Mesmo assim, muitos desenvolvedores podem não se importar em como este código possa parecer. Uma questão de gosto, talvez.
Podemos então usar como argumento uma autoridade. Brian Goetz, arquiteto de linguagem da Oracle, certa vez disse em uma conferência que o Optional foi criado para resolver um problema de retorno dos dados e não de entrada, ao tratar sobre o mesmíssimo assunto.
Se você se convenceu, a próxima pergunta será: o que fazer, então?
Existem diferentes respostas para esta pergunta. A minha preferida, por ser aplicável na maioria dos casos, é ter um método diferente para cada situação. Pegando o exemplo anterior, se é possível criar uma pessoa apenas com nome ou com nome e sobrenome, podemos ter um método para cada caso, usando overloading:
Deixando as chamadas bem mais simples de entender. Compare com a solução utilizando Optional no parâmetro:
Inclusive, esta mesma ideia pode ser aplicada para evitar parâmetros booleanos no código: criar diferentes métodos.
Se null é ruim, posso usar Optional para tudo?
No Java não é possível. O Optional não foi criado para abolir o null de todos os contextos possíveis. Veja alguns locais onde o Optional não é bem-vindo:
- em entidades e DTOs, por não serem serializáveis;
- como parâmetro de entrada em um método ou como parâmetro de construtor, pelos motivos explicados anteriormente.
A ideia do texto foi dar uma visão geral do bom uso de Optional e casos onde ele não é aplicável. A utilização do Optional já alcançou os frameworks mais populares, então é o momento de exercitar o conceito e aplicá-lo corretamente no seu projeto.
