Doit toutes les propriétés d'un objet immuable finale?

La principale différence entre un objet immuable (toutes les propriétés finales) et, effectivement, une immuable objet (propriétés ne sont pas définitives, mais ne peut pas être changé) est sûr de publication.

Vous pouvez publier une immuable objet dans un contexte multithread sans avoir à vous soucier de l'ajout de la synchronisation, grâce à la les garanties offertes par la Java de la Mémoire de Modèle pour la finale champs:

finale des domaines aussi permettre aux programmeurs de mettre en œuvre thread-safe des objets immuables, sans synchronisation. Un thread-safe immuable objet est considéré comme immuable par tous les threads, même si une course est utilisé pour transmettre des références à l'immuable objet entre les threads. Cela peut fournir des garanties de sécurité contre l'utilisation abusive de immuable de classe en raison d'une erreur ou d'un code malveillant. final champs doivent être utilisées correctement pour fournir une garantie de l'immuabilité.

Comme une note de côté, il permet aussi d'appliquer l'immutabilité (si vous essayez de muter ces champs dans une future version de votre classe parce que vous avez oublié, il devrait être immuable, il ne compile pas).

---

Précisions

• Faire tous les champs d'un objet final n'est pas immuable - vous devez également vous assurer que (i) l'état ne peut pas changer (par exemple, si l'objet contient un final List, aucune mutation de l'exploitation (ajouter, supprimer,...) doit être fait après la construction) et (ii) vous ne laissez pas this échapper lors de la construction
• Effectivement, une immuable objet est thread-safe une fois qu'il a été en toute sécurité publié

• Exemple de dangereux publication:

  class EffectivelyImmutable {
      static EffectivelyImmutable unsafe;
      private int i;
      public EffectivelyImmutable (int i) { this.i = i; }
      public int get() { return i; }
  }
  
  //in some thread
  EffectivelyImmutable.unsafe = new EffectivelyImmutable(1);
  
  //in some other thread
  if (EffectivelyImmutable.unsafe != null
      && EffectivelyImmutable.unsafe.get() != 1)
      System.out.println("What???");

  Ce programme pourrait, en théorie, d'impression What???. Si i étaient final, ce ne serait pas un résultat juridique.

Immuable = non modifiables. Afin d'apporter des propriétés final est une bonne idée. Si pas toutes les propriétés d'un objet sont protégés d'être changé, je ne dirais pas que l'objet est immuable.

MAIS d'un objet est aussi immuable que si elle ne fournit pas toutes les setters pour les propriétés privées.

Le simple fait de déclarer un objet comme final ne fait pas de soi immuable. Prenez l'exemple de ce classe:

import java.util.Date;

/**
* Planet is an immutable class, since there is no way to change
* its state after construction.
*/
public final class Planet {

  public Planet (double aMass, String aName, Date aDateOfDiscovery) {
     fMass = aMass;
     fName = aName;
     //make a private copy of aDateOfDiscovery
     //this is the only way to keep the fDateOfDiscovery
     //field private, and shields this class from any changes that 
     //the caller may make to the original aDateOfDiscovery object
     fDateOfDiscovery = new Date(aDateOfDiscovery.getTime());
  }

  /**
  * Returns a primitive value.
  *
  * The caller can do whatever they want with the return value, without 
  * affecting the internals of this class. Why? Because this is a primitive 
  * value. The caller sees its "own" double that simply has the
  * same value as fMass.
  */
  public double getMass() {
    return fMass;
  }

  /**
  * Returns an immutable object.
  *
  * The caller gets a direct reference to the internal field. But this is not 
  * dangerous, since String is immutable and cannot be changed.
  */
  public String getName() {
    return fName;
  }

// /**
// * Returns a mutable object - likely bad style.
// *
// * The caller gets a direct reference to the internal field. This is usually dangerous, 
// * since the Date object state can be changed both by this class and its caller.
// * That is, this class is no longer in complete control of fDate.
// */
// public Date getDateOfDiscovery() {
//   return fDateOfDiscovery;
// }

  /**
  * Returns a mutable object - good style.
  * 
  * Returns a defensive copy of the field.
  * The caller of this method can do anything they want with the
  * returned Date object, without affecting the internals of this
  * class in any way. Why? Because they do not have a reference to 
  * fDate. Rather, they are playing with a second Date that initially has the 
  * same data as fDate.
  */
  public Date getDateOfDiscovery() {
    return new Date(fDateOfDiscovery.getTime());
  }

  //PRIVATE //

  /**
  * Final primitive data is always immutable.
  */
  private final double fMass;

  /**
  * An immutable object field. (String objects never change state.)
  */
  private final String fName;

  /**
  * A mutable object field. In this case, the state of this mutable field
  * is to be changed only by this class. (In other cases, it makes perfect
  * sense to allow the state of a field to be changed outside the native
  * class; this is the case when a field acts as a "pointer" to an object
  * created elsewhere.)
  */
  private final Date fDateOfDiscovery;
}

Classe String est Immuable, mais bien de hachage n'est pas définitive

Et bien c'est possible, mais avec quelques règles ou des restrictions et qui est de l'accès à mutable propriétés/champs doivent fournir le même résultat à chaque fois que nous avons accès à elle.

Classe String hashcode effectivement calculés sur le dernier tableau de caractères qui ne va pas changer si la Chaîne a construit. Donc immuable classe peut contenir des champs mutables/propriétés, mais il doit s'assurer que l'accès à terrain/propriété produira le même résultat à chaque fois qu'il est accessible.

Pour répondre à votre question, il n'est pas obligatoire d'avoir tous les champs de finale dans un immuable classe.

Pour en savoir plus rendez-vous ici [blog] : http://javaunturnedtopics.blogspot.in/2016/07/string-is-immutable-and-property-hash.html