He leído que con una versión de Java menor que 7, los objetos Joda Time son más confiables que los integrables de Java. Una razón citada es que los objetos Joda son inmutables. ¿Por qué es esto beneficioso? Si deseo cambiar el año, la hora y la zona horaria de un objeto Joda DateTime, ¡necesito hacer tres copias!¿Por qué los objetos Joda son inmutables?
Si deseo cambiar el año, la hora y la zona horaria de un objeto Joda DateTime, ¡tengo que hacer tres copias!
Sí, de hecho. O puede crear un nuevo objeto, utilizando todos los campos que desee del objeto anterior, por supuesto.
Esto es algo muy bueno, porque significa que cuando quieres confiar en que un objeto no cambia, no lo hará. Considere este pseudo-código:
private static final Instant EARLIEST_ALLOWED_ARTICLE = ...;
private Instant creationTimestamp;
public Article(Instant creationTimestamp, ...) {
if (creationTimestamp.isBefore(EARLIEST_ALLOWED_ARTICLE)) {
throw new IllegalArgumetnException(...);
}
this.creationTimestamp = creationTimestamp;
...
}
eso está bien, porque Instant es inmutable. Si fuera mutable, la validación en el constructor sería inútil, a menos que haya creado una copia defensiva en ese punto.
En mi experiencia, que desea pasar alrededor de referencias y saber que los valores no cambiarán más de lo que quiere hacer realidad cambios en los objetos existentes, por lo que la inmutabilidad conduce a un menor número de errores (con objetos mutables se puede olvidar tomar una copia, y cualquier validación es inútil) y se hacen menos copias.
Básicamente, le permite razonar sobre su código localmente sin hacer copias de todo lo que acepte y almacene, o regrese a otro código. Cuando solo su código puede cambiar el estado de su objeto, es mucho más simple resolver lo que sucederá con el tiempo.
Joda tiempo realmente falla un poco, ya que tiene dos mutables y tipos inmutables - si sólo programa en la interfaz (por ejemplo ReadableInstant), entonces usted no recibe esas garantías. Es por eso que en Noda Time hice todos los tipos genuinamente inmutables.
Fuera de interés, ¿le gustaría que String fuera mutable? Si no, intente pensar si existen diferencias reales entre los dos escenarios.
Estos son excelentes puntos. Pero, ¿son realmente las fechas algo especial, como los "primitivos" (números y cadenas) que son inmutables? Lo que describes nos lleva a la pregunta de por qué no debemos hacer que * todas * las clases sean mutables y por qué no * cada * setter * ever * está haciendo una copia antes de cambiar el valor. Realmente no tiene sentido escribir 'clone' o' copy' en cada setter que escriba. Esto sugiere un problema fundamental, en cambio. – caw
@caw: Sí, yo diría que las fechas realmente * son * algo especial. Definitivamente puede ser conveniente tener tipos mutables, aunque en general * prefiero los inmutables cuando sea posible. Pero si los tipos "primitivos" de bajo nivel fueran todos mutables, entonces esa * elección * de mutabilidad o inmutabilidad sería mucho más difícil de implementar ... las clases inmutables tendrían que clonar todo * todo el tiempo *. Urgh. –
¡Gracias! Realmente no veo la gran diferencia entre fechas y otros objetos comunes (por ejemplo, Colecciones, 'Calendario', objetos de la lógica comercial). De todos modos, hay una diferencia * sustancial * entre los objetos que * no * se * cambian más tarde (y, por lo tanto, pueden no tener ningún setter público, de todos modos), donde solo necesitas clonar los datos que recibes en tus constructores/setters (como en el ejemplo anterior de 'Artículo', que también es lo que Joshua Bloch recomienda en "Java efectivo"), y los objetos * que * están destinados a cambiar, que luego deben copiarse en cada incubadora. – caw
La respuesta más simple es que una vez que crea un objeto, sabe que no puede cambiar. Esto significa que no se encontrará con una situación en la que sus datos cambien de forma inesperada (en otras partes del código o en diferentes hilos, tal vez).
Esto hace que el comportamiento del objeto sea más predecible y confiable.
Puede haber muchas razones, pero una buena tiene que ver con el hash. Los objetos inmutables se pueden usar en estructuras de datos hash (por ejemplo, HashSet, claves en HashMaps, etc.) porque su código de hash y semántica de "igualdad" no cambiará. Los objetos mutables no son adecuados para hash ya que las mutaciones pueden cambiar su código hash o igualdad.
Al hacer que las fechas Joda sean inmutables, ahora se pueden usar en estructuras de datos hash.
yo supongo que es debido a esto:
Imagine que tiene un java.util.Date a objetos, que se utiliza en múltiples clases. Estoy haciendo desarrollo en una clase, tú en la otra. Luego, decido que necesito predecir el futuro, pero en lugar de crear un nuevo objeto Date, tomo el que ya tengo, el que cree que representa un cierto momento, y le agrego tres horas. Ahora, su código podría encontrarse con serios problemas en el tiempo de ejecución. Esto se puede evitar utilizando un objeto inmutable, ya que no puede cambiar su estado, no puede estropearlo para nadie más.
Desafortunadamente, la implementación de DateTime no es inmutable [1], ya que no se utiliza final.
https://github.com/JodaOrg/joda-time/blob/master/src/main/java/org/joda/time/DateTime.java
[1] el término "inmutable" se entiende comúnmente para significar "thread-safe inmutable".
Por el contrario, si sus objetos DateTime no son inmutables, * se supone * que lo clonará cada vez que lo pase como parámetro a una API de terceros ... dado que Java no tiene 'const'. –