Parece realmente fedorento e, sem ver mais contexto, é impossível dizer com certeza. Pode haver duas razões para isso, embora haja alternativas para ambos.
Primeiro, é uma maneira concisa de implementar a conversão parcial ou deixar o resultado com valores padrão se a conversão falhar. Ou seja, você pode ter isto:
public void ConvertFoo(Foo from, Foo to) {
if (can't convert) {
return;
}
...
}
Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged
Claro, geralmente isso é tratado usando exceções. No entanto, mesmo que as exceções precisem ser evitadas por qualquer motivo, há uma maneira melhor de fazer isso - o Padrão TryParse sendo uma opção.
Outra razão é que poderia ser por razões puramente de consistência, por exemplo, é parte de uma API pública onde este método é usado para todas as funções de conversão por qualquer motivo (como outras funções de conversão com múltiplas saídas).
O Java não é ótimo em lidar com várias saídas - ele não pode ter parâmetros somente de saída, como alguns idiomas, ou ter vários valores de retorno como outros - mas, mesmo assim, você poderia usar objetos de retorno.
A razão de consistência é bastante fraca, mas infelizmente pode ser a mais comum.
- Talvez os policiais de estilo em seu local de trabalho (ou em sua base de código) tenham origem não-Java e tenham relutado em mudar.
- Seu código pode ter sido uma porta de um idioma em que esse estilo é mais idiomático.
- Sua organização pode precisar manter a consistência da API em diferentes idiomas, e esse era o estilo de menor denominador comum (é estúpido, mas acontece mesmo para o Google ).
- Ou talvez o estilo tenha feito mais sentido no passado distante e tenha se transformado em sua forma atual (por exemplo, poderia ter sido o padrão TryParse, mas algum predecessor bem intencionado removeu o valor de retorno depois de descobrir que ninguém o verificou) .