Clonar() vs Copiar constructor - que se recomienda en java

Question

clonar método vs copiar constructor en java. cuál es la solución correcta. dónde usar cada caso?

Answer 1

El clon está roto, así que no lo use.

EL MÉTODO clon de la clase Object es un método algo mágico que hace lo que ningún método Java pura jamás podría hacer: Produce una copia idéntica de su objeto. Ha estado presente en la superclase Objeto primordial desde Días de publicación beta del compilador Java *; y, como todos antigua magia, requiere la encantamiento apropiado para prevenir el hechizo de inesperadamente backfiring

prefiere un método que copia el objeto

Foo copyFoo (Foo foo){ 
    Foo f = new Foo(); 
    //for all properties in FOo 
    f.set(foo.get()); 
    return f; 
} 

Más http://adtmag.com/articles/2000/01/18/effective-javaeffective-cloning.aspx

Answer 2

Tenga en cuenta que clone() no funciona de la caja. Deberá implementar Cloneable y anular el método clone() en public.

Hay algunas alternativas, que son preferibles (ya que el método clone() tiene un montón de problemas de diseño, como se ha dicho en otras respuestas), y el constructor de copia requeriría el trabajo manual:

• BeanUtils.cloneBean(original) crea un clon superficial, como el creado por Object.clone(). (esta clase es de commons-beanutils)

• SerializationUtils.clone(original) crea una copia profunda. (Es decir, todo el gráfico propiedades se clona, ​​no sólo el primer nivel) (de commons-lang), pero todas las clases deben implementar Serializable

• Java Deep Cloning Library ofrece la clonación de profundidad sin la necesidad de implementar Serializable

Answer 3

Véase también : How to properly override clone method?. La clonación se rompe en Java, es tan difícil para hacerlo bien, e incluso cuando lo hace realmente no ofrece mucho, por lo que realmente no vale la pena la molestia.

Answer 4

Tenga en cuenta que el constructor de copia limita el tipo de clase al del constructor de copia. Considere el ejemplo:

// Need to clone person, which is type Person 
Person clone = new Person(person); 

Esto no funciona si person podría ser una subclase de Person (o si Person es una interfaz). Este es el punto principal de la clonación, es que puede clonar el tipo apropiado dinámicamente en el tiempo de ejecución (suponiendo que el clon esté implementado correctamente).

Person clone = (Person)person.clone(); 

o

Person clone = (Person)SomeCloneUtil.clone(person); // See Bozho's answer 

Ahora person puede ser cualquier tipo de Person asumiendo que clone se implementa correctamente.

Answer 5

clone() se diseñó con varios errores (consulte this question), por lo que es mejor evitarlo.

De Effective Java 2nd Edition, Tema 11: clon de anulación juiciosamente

Teniendo en cuenta todos los problemas asociados con Cloneable, es seguro decir que otras interfaces no deben extenderse, y que las clases diseñados para la herencia (artículo 17) no debería implementarlo. Debido a sus muchas deficiencias, algunos programadores expertos simplemente eligen nunca anular el método de clonación y nunca invocarlo excepto, tal vez, a copiar matrices. Si diseña una clase para herencia, tenga en cuenta que si elige no proporcionar un método de clonación protegido con buen comportamiento, será imposible que las subclases implementen Clonación.

Este libro también describe las muchas ventajas que tienen los constructores de copia sobre Cloneable/clone.

• Ellos no se basan en un mecanismo de creación de objetos extralinguistico propensos al riesgo
• No exigen la adhesión a las convenciones inaplicable escasamente documentados
• no entren en conflicto con el uso adecuado de los campos finales
• No lanzan excepciones marcadas innecesarias
• No requieren moldes.

Todas las colecciones estándar tienen constructores de copias. Usalos, usalos a ellos.

List<Double> original = // some list 
List<Double> copy = new ArrayList<Double>(original); 

Answer 6

gran tristeza: ni Cloneable/clon ni un constructor son grandes soluciones: NO QUIERO SABER LA IMPLEMENTACIÓN DE CLASE !!! (por ejemplo, tengo un mapa, que quiero copiar, usando la misma implementación oculta de MumbleMap). Solo quiero hacer una copia, si es compatible. Pero, por desgracia, Cloneable no tiene el método de clonación, por lo que no hay nada a lo que pueda escribir de forma segura para invocar clone().

Sea cual sea la mejor biblioteca de "objetos copiados" que exista, Oracle debería convertirla en un componente estándar de la próxima versión de Java (a menos que ya esté oculta en algún lugar).

Por supuesto, si más de la biblioteca (por ejemplo, Colecciones) son inmutables, esta tarea de "copia" simplemente desaparecerá. Pero luego comenzamos a diseñar programas Java con cosas como "invariantes de clase" en lugar de verdammt "patrón de frijol" (hacer un objeto roto y mutar hasta que sea bueno [suficiente]).