make - java.util.Date clone o copie para no exponer la referencia interna

make object copy java

Question

Lo mejor es no exponer las referencias internas de un Objeto (Entidad). Por lo tanto, si un objeto tiene un campo de tipo java.util.Date , por ejemplo, el getter para este campo no debe devolver la fecha original, sino una copia.

Pero para un java.util.Date hay dos formas comunes de crear esa copia:

• clonar: (Date) originalDate.clone()
• copiar mediante constructor new Date(originalDate.getTime())

Mi pregunta es, ¿qué camino es mejor y por qué?

Answer 1

Lee Effective Java . La forma preferida de crear copias es usar el enfoque del constructor de copias.

Bill Venners: en tu libro, recomendamos usar un constructor de copia en lugar de implementar Cloneable y escribir clon. ¿Podrías profundizar en eso?

Josh Bloch: Si has leído el artículo sobre la clonación en mi libro, especialmente si lees entre líneas, sabrás que creo que el clon está profundamente roto. Hay algunos defectos de diseño, el mayor de los cuales es que la interfaz Cloneable no tiene un método de clonación. Y eso significa que simplemente no funciona: hacer algo clonable no dice nada sobre lo que puedes hacer con él. En cambio, dice algo acerca de lo que puede hacer internamente. Dice que si al llamar a super.clone repetidamente termina llamando al método de clonación de Object, este método devolverá una copia de campo del original.

Answer 2

Si definitivamente es solo una Date , no hará ninguna diferencia de ninguna manera.

Si el objeto real puede ser una subclase de Date (como java.sql.Date ), entonces espero que clone() preserve la información adicional (incluida la clase que es), mientras que llamar al constructor no lo haría.

Por otro lado, si usaste Joda Time no tendrías este problema, ya que hay muchos tipos inmutables para usar. También es una API mucho mejor :)

Answer 3

Si está codificando a la defensiva, querrá el constructor de copias. Vea este pasaje de Effective Java :

Tenga en cuenta también que no usamos el método de clonación de Date para hacer las copias defensivas. Como Date no es final, no se garantiza que el método clon devuelva un objeto cuya clase sea java.util.Date; podría devolver una instancia de una subclase no confiable específicamente diseñada para daños maliciosos. Dicha subclase podría, por ejemplo, registrar una referencia a cada instancia en una lista privada estática en el momento de su creación y permitir al atacante acceder a esta lista. Esto le daría al atacante dominio libre sobre todas las instancias. Para evitar este tipo de ataque, no use el método de clonación para hacer una copia defensiva de un parámetro cuyo tipo sea subclassable por partes no confiables.