Está mutando-objeto parámetros en un método (en Java) es una mala práctica?

MaverinCode:

Tengo una pregunta acerca de métodos mutando-Paramaters (que son objetos) en un método.

He leído y oído varias veces que es una mala práctica de mutar un objeto en un método que fue aprobada en un parámetro de. Como ejemplo:

public void modifyList(List<Object> list) {
    list.add(new Object());
}

En cambio, la aprobada en objeto debe ser copiada, la mutación se debe realizar en el objeto copiado y el objeto copiado debe ser devuelto. Como ejemplo:

public List<Object> getModifiedList(List<Object> list) {
    List copy = new List<Object();
    //Make a deep copy if it would be necessary
    for(Object o : list) {
        copy.add(o.clone());
    }
    //Modify the copy
    copy.add(new Object());
    //return the copy
    return copy;
}

Entiendo que el segundo método tiene menos potencial de efectos secundarios, ya que no muta el parámetro de entrada.

Pero ¿es realmente el camino a seguir? El rendimiento sufriría debido a que una gran cantidad de copys profundas tienen que ser creados. También le costaría mucho tiempo implementar Copy-Constructores e implementar clon de métodos para todas las clases. También aumentaría la inmensa LOC.

En la práctica, no veo este patrón (copiar el método de parámetros) a menudo.

Podría alguien con mucha experiencia (trabajando como desarrollador / programador de software desde hace años) responder a esto?

saludos Maverin

assylias:

Ambos métodos están bien y podría ser la elección correcta dependiendo de su caso de uso. Sólo asegúrese de que usted los nombra en una forma que tenga la intención clara y escribir algunos javadoc.

Es entonces responsabilidad del desarrollador para decidir si tener la lista original mutado está bien o no, y si no, pasar una copia o el uso de un método diferente.

Por ejemplo, este método de las muta JDK una lista existente, pero su intención y la documentación son muy claras.