¿Modificar un parámetro entrante es un antipatrón? [cerrado]

Estoy programando en Java, y siempre hago convertidores de esta manera:

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

En el nuevo lugar de trabajo, el patrón es:

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

Para mí es un poco maloliente, ya que me acostumbré a no cambiar los parámetros entrantes. ¿Es esta alteración del parámetro entrante un antipatrón o está bien? ¿Tiene algunos inconvenientes serios?

No es un antipatrón, es una mala práctica.

La diferencia entre un antipatrón y una mera mala práctica está aquí: definición antipatrón .

El nuevo estilo de lugar de trabajo que muestra es una mala práctica , tiempos de vestigio o pre-OOP, de acuerdo con el Código de limpieza del tío Bob.

Los argumentos se interpretan más naturalmente como entradas a una función.

Cualquier cosa que lo obligue a verificar la firma de la función es equivalente a una doble toma. Es una ruptura cognitiva y debe evitarse. En los días previos a la programación orientada a objetos, a veces era necesario tener argumentos de salida. Sin embargo, gran parte de la necesidad de argumentos de salida desaparece en los lenguajes OO

Citando el famoso libro de Robert C. Martin "Código limpio":

Deben evitarse los argumentos de salida

Las funciones deben tener un pequeño número de argumentos.

El segundo patrón viola ambas reglas, particularmente el "argumento de salida". En este sentido, es peor que el primer patrón.

El segundo idioma puede ser más rápido, porque la persona que llama puede reutilizar una variable en un ciclo largo, en lugar de que cada iteración cree una nueva instancia.

Generalmente no lo usaría, pero por ejemplo. en la programación de juegos tiene su lugar. Por ejemplo, mire las muchas operaciones Vector3f de JavaMonkey que permiten pasar instancias que deberían modificarse y devolverse como resultado.

No creo que sean dos códigos equivalentes. En el primer caso, debe crear el otherObject. Puede modificar la instancia existente en el segundo. Ambos tienen sus usos. El olor a código preferiría uno sobre otro.

Realmente depende del idioma.

En Java, la segunda forma puede ser un antipatrón, pero algunos lenguajes tratan el paso de parámetros de manera diferente. En Ada y VHDL por ejemplo, en lugar de pasar por valor o por referencia, los parámetros pueden tener modos in, outo in out.

Es un error modificar un inparámetro o leer un outparámetro, pero cualquier cambio en un in outparámetro se devuelve a la persona que llama.

Entonces, las dos formas en Ada (también son VHDL legales) son

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

y

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

Ambos tienen sus usos; un procedimiento puede devolver múltiples valores en múltiples Outparámetros mientras que una función solo puede devolver un único resultado. Debido a que el propósito del segundo parámetro está claramente establecido en la declaración del procedimiento, no puede haber objeciones a este formulario. Tiendo a preferir la función de legibilidad. pero habrá casos en los que el procedimiento es mejor, por ejemplo, donde la persona que llama ya ha creado el objeto.

De hecho, parece maloliente, y sin ver más contexto es imposible decirlo con certeza. Podría haber dos razones para hacerlo, aunque existen alternativas para ambos.

Primero, es una forma concisa de implementar una conversión parcial, o dejar el resultado con valores predeterminados si la conversión falla. Es decir, podrías 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 las excepciones deben evitarse por cualquier razón, hay una mejor manera de hacerlo: el patrón TryParse es una opción.

Otra razón es que podría ser por razones puramente consistentes, por ejemplo, es parte de una API pública donde este método se usa para todas las funciones de conversión por cualquier razón (como otras funciones de conversión que tienen múltiples salidas).

Java no es excelente para lidiar con múltiples salidas: no puede tener parámetros de solo salida como algunos lenguajes, o tener múltiples valores de retorno como otros, pero aún así, podría usar objetos de retorno.

La razón de la coherencia es poco convincente, pero lamentablemente puede ser la más común.

• Quizás los policías de estilo en su lugar de trabajo (o su base de código) provienen de un entorno que no es Java y han sido 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 coherencia de la API en diferentes idiomas, y este fue el estilo de denominador común más bajo (es tonto pero sucede incluso para Google ).
• O tal vez el estilo tenía más sentido en el pasado distante 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ó en absoluto).

La ventaja del segundo patrón es que obliga a la persona que llama a tomar posesión y responsabilidad del objeto creado. No hay duda de si el método creó o no el objeto o lo obtuvo de un grupo reutilizable. La persona que llama sabe que es responsable de la vida útil y la eliminación del nuevo objeto.

Las desventajas de este método son:

1. No se puede utilizar como método de fábrica, la persona que llama debe conocer el subtipo exacto OtherObjectque necesita y construirlo con anticipación.
2. No se puede usar con objetos que requieren parámetros en su constructor si esos parámetros provienen MyObject. OtherObjectdebe ser construible sin saberlo MyObject.

La respuesta se basa en mi experiencia en c #, espero que la lógica se traduzca a Java.

Dada la semántica laxa, myObjectToOtherObjectpodría significar igualmente que mueve algunos datos del primer objeto al segundo o que los convierte completamente de nuevo, el segundo método parece más adecuado.

Sin embargo, si el nombre del método fuera Convert(lo que debería ser si miramos la parte "... hacer la conversión"), diría que el segundo método no tendría ningún sentido. No convierte un valor en otro valor que ya existe, IMO.