Práctica Java: devolver el mismo objeto que se pasó como parámetro

En el siguiente código, ¿es realmente una mala práctica para updateWithContex devolver el mismo objeto que tomó como parámetro?Práctica Java: devolver el mismo objeto que se pasó como parámetro

class SomeClass{ 
    Foo updateWithContex(Foo foo){ 
     foo.setAppId(i); 
     foo.setXId(index); 
     //..... 
     return foo; 
    } 
} 

class Foo{ 

    public void setAppId(int appId) 
    { 
     // 
    } 
    public void setXId(int appId) 
    { 
     // 
    } 
    public void changeState(X x) 
    { 
     // 
    } 
}

En C++, he visto código como este:

BigObject& 
    fastTransform(BigObject& myBO) 
    { 
     // When entering fastTransform(), myBO is the same object as the function 
     // argument provided by the user. -> No copy-constructor is executed. 
     // Transform myBO in some way 
     return myBO; // Transformed myBO is returned to the user. 
    }

¿Es esto también sucede?

Fuente

2012-01-26 yadab

El método de encadenamiento es un poco diferente, devuelve una referencia al objeto al que se llamó el método, no al objeto que se pasó como parámetro como en este caso. – buc

@buc: cierto, buen punto. Fui demasiado rápido, luego –

La devolución de un objeto sugerirá a los usuarios de su abi que el objeto pasado no se cambiará y en su lugar se devolverá un nuevo objeto modificado. Para dejar en claro que este no es el caso, sugeriría cambiar el tipo de devolución a void.

Fuente

2012-01-26 08:26:38

¡Esto tiene sentido! Pero, ¿es fundamentalmente erróneo? o es solo la legibilidad del Código? – yadab

Depende de cómo se defina "fundamentalmente erróneo" ... ¿Hace que el método sea imposible de usar? No. ¿Su nombre será maldecido por alguien más que tenga que llamar a su método? ¡Probablemente! – vaughandroid

@vaughandroid ¿cuál es una mejor manera de manejar esto, entonces? – user11235813

El código debería tener este aspecto:

class SomeClass{ 
    void updateWithContex(Foo foo){ 
     foo.setAppId(i); 
     foo.setXId(index); 
     //..... 
    } 
}

Es una mala práctica, debido a que pase la referencia al objeto foo, por lo que se puede cambiar en el método updateWithContex sin volver de nuevo al método. Una vez más, recuerda que trabajas siempre con referencia a Java. Y, por supuesto, no hay forma de hacerlo en otro lugar: siempre será una referencia a un objeto. Java no tiene nada como esto: fastTransform (BigObject & myBO).

Fuente

2012-01-26 08:21:56

Fwiw, esperaría que updateWithContext sea privado, y hasta este punto, el tipo de devolución no es muy importante. Si tiene métodos públicos que modifican el estado interno de Foo, los declararía como miembros vacíos de Foo. –

Sé cómo funciona la referencia de Java, es por eso que he proporcionado refs de C++ para aclarar la necesidad. Mi pregunta es: ¿Por qué está mal devolver Same Foo? Cuando programamos con el ensamblado, el mismo registro cambia y retrocede, ¿por qué no en Java? – yadab

@Savino Sguera - updateWithContext es un paquete privado. –

No veo nada malo, es una cuestión de diseño de API. Con el código que ha publicado se puede hacer algo como

someClass.updateWithContext(new Foo()).changeState(x);

en lugar de

Foo foo = new Foo(); 
someClass.updateWithContext(foo); 
foo.changeState(x);

El primer fragmento de código es un mejor ejemplo de fluent interface que el segundo.

Fuente

2012-01-26 08:23:27 frm

Gracias! Pero mi caso es ligeramente diferente de lo que respondiste (el método de encadenamiento no es mi problema). – yadab

Output Parameters in Java algunos objetos son mutables e inmutables. La seguridad de la rosca de tales métodos también es dudosa. Se puede hacer, pero sí, generalmente se considera que no es algo bueno, y google también para los parámetros de java de salida. Espero que esto ayude.

Fuente

2012-01-26 08:32:25

Práctica Java: devolver el mismo objeto que se pasó como parámetro

Respuesta

Cuestiones relacionadas