De hecho, parece maloliente, y sin ver más contexto es imposible decirlo con seguridad. Podría haber dos razones para hacer esto, aunque hay alternativas para ambos.
Primero, es una forma concisa de implementar una conversión parcial o dejar el resultado con los valores predeterminados si la conversión falla. Es decir, podría tener esto:
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
Por supuesto, generalmente esto se maneja usando excepciones. Sin embargo, incluso si es necesario evitar las excepciones por cualquier motivo, hay una mejor manera de hacerlo: TryParse patrón es una opción.
Otra razón es que podría ser por razones puramente de coherencia, por ejemplo, es parte de una API pública donde se utiliza este método para todas las funciones de conversión por cualquier razón (como otras funciones de conversión que tienen varias salidas).
Java no es bueno para manejar múltiples salidas, no puede tener parámetros de solo salida como algunos idiomas, o tener múltiples valores de retorno como otros, pero aún así, puede usar objetos de retorno.
La razón de la consistencia es bastante escasa, pero lamentablemente puede ser la más común.
- Tal vez los policías de estilo en su lugar de trabajo (o su código base) provienen de un fondo que no es de Java y se han mostrado reacios a cambiar.
- Su código puede haber sido un puerto de un idioma donde este estilo es más idiomático.
- Es posible que su organización necesite mantener la consistencia de la API en diferentes idiomas, y este fue el estilo de denominador común más bajo (es absurdo, pero sucede incluso para Google ).
- O tal vez el estilo tenía más sentido en el pasado lejano y se transformó en su forma actual (por ejemplo, podría haber sido el patrón TryParse pero algún predecesor bien intencionado eliminó el valor de retorno después de descubrir que nadie lo comprobó) .