Effective Java afirma que elements.clone () basta

justgivememyicecream:

Estoy leyendo sobre Joshua Bloch Effective Java, 2ª edición , artículo 11: clon de anulación juiciosamente.

En la página 56, que está tratando de explicar que cuando sobreescribimos clone()para algunas clases (como clases de colección), hay que copiar el funcionamiento interno de la misma . A continuación, da el ejemplo de diseño de una clase Stack:

public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;
    public Stack() {...}
    public void push(Object e) {...}
    public Object pop() {...}
    private void ensureCapacity() {...} //omitted for simplicity
}

Afirma que si simplemente usamos super.clone()para clonar una Stack, la instancia de la pila resultante "tendrá el valor correcto en su campo de tamaño, pero su campo de elementos se referirá a la misma matriz que la instancia Pila originales. Modificar el original destruirá los invariantes en el clon y viceversa. Usted encontrará rápidamente que su programa produce resultados sin sentido o lanza una NullPointerException ". Ahora que parece justo. Pero luego da un ejemplo de la "aplicación correcta", lo que me confunde:

@Override public Stack clone() {
    try {
        Stack result = (Stack) super.clone();
        result.elements = elements.clone();
        return result;
    } catch (CloneNotSupportedException e) {
        throw new AssertionError();
    }
}

Ahora bien, ¿es tan diferente de super.clone()? Yo sé, el nuevo Stack.elementhabrá una referencia diferente que el anterior y todos; pero los "internos" de la matriz siguen siendo los mismos, no son? Los elementos reales de la matriz result.elementtodavía apuntan a los originales Objectreferencias. Que aún podría resultar en la destrucción de los invariantes del clon cuando se cambia el original, o viceversa, no podría? Me estoy perdiendo algo?

barredora:

Tiene toda la razón acerca de cómo clonefunciona. Los objetos de la matriz de soporte no se copiarán, pero se copiarán la matriz de soporte.

Eso no es un problema, ya que la persona que llama no está esperando los elementos a copiar todos modos. Para las clases de colección, como pilas, la "norma" es hacer una copia superficial. Un ejemplo de la biblioteca estándar es el constructor copia ArrayList.

También tenga en cuenta que podría poner en práctica clonemediante la clonación de los objetos dentro de la matriz, así (esto significaría que la pila sólo puede almacenar Clonableobjetos que exponen clone). Eso no sería romper el contrato de clone. El contrato es muy floja.