Existe alguma razão para não usar o Opcional como argumento de método no caso em que você sabe que o argumento é algo que pode ou não ser necessário?

No Java 8, eu tenho visto mais e mais artigos sobre o uso do Option / Optional. Entendo o que eles estão tentando representar e vejo muitos exemplos deles sendo usados ​​como retornos. No entanto, o que eu não vejo é que eles estão sendo usados ​​como argumentos de método / função em linguagens que não possuem a sintaxe para parâmetros padrão / opcionais.

Existe alguma razão para não usar Optionalcomo argumento de método no caso em que você sabe que o argumento é algo que pode ou não ser necessário? Aqui está um exemplo que eu poderia pensar:

Optional<Customer> lookupCustomer(String firstName, Optional<String> middleName, String lastName)

Uma razão é que, conceitualmente, firstName, middleName, e lastNamesão logicamente um argumento, e não três. São todas partes de um todo maior, e pode-se imaginar que quase sempre são passadas juntas. Em linguagens funcionais, eles provavelmente seriam passados ​​como uma tupla ou registro; O Java não possui, portanto eles provavelmente seriam agregados em uma classe Name. Observe que se você precisasse compor funções que recebem e retornam nomes completos, não seria possível sem agregá-las - você só pode retornar um valor, afinal.

Talvez não surja com muita frequência que um valor seja opcional e também não faça parte de um todo maior. Se a função exigir um certo valor para fazer seu trabalho, essa função não deverá aceitar um Optional. Se você precisar encadear operações que talvez não retornem um valor, interrompendo Nothingse alguma função ao longo do caminho falhar, poderá encadear chamadas e flatMap, se desejar falhar com uma exceção, poderá usá-lo get()em qualquer etapa do processo. fim da cadeia.

Se um valor é verdadeiramente opcional e uma função faz duas coisas diferentes com base em sua presença ou ausência, isso é um cheiro de código, a menos que a função seja um invólucro de duas funções menores que fazem uma coisa cada, e essa combinação específica de decisões é muito comum.

Não acho que seja errado, pois é um caso de uso relativamente incomum.

Não há muitos idiomas que não suportem argumentos padrão; portanto, esse não é um uso comum. Pessoalmente, acho que seu uso não é terrível, mas não será Java idiomático. Java intencionalmente não possui argumentos padrão, para forçar o uso de sobrecarga, o que tem a vantagem do compilador verificar seus argumentos em vez de exigir ifinstruções dentro da função.

Em outras palavras, você criará duas versões diferentes da consulta: uma com um nome do meio e outra sem. Se você puder fazer isso de maneira concisa, usar uma opção é uma boa ideia. Se for detalhado o suficiente para você querer duas funções separadas, use a sobrecarga e faça-a idiomática.