#AstuceDeCode 10 : les objets immutables

En Java nous avons la possibilité d’utiliser des objets immutables. Il s’agit d’objets, qui une fois initialisés, ne peuvent plus être modifiés. L’intérêt est notamment d’avoir des objets qui sont par définition thread safe, ce qui permet d’éviter d’avoir des blocs synchronized autour de ces objets. Dans cet article nous voyons comment créer ces objets, quand les utiliser ainsi que leurs avantages et inconvénients.

Débloque les + belles offres tech en 10 mins

La création d’objets immutables

Créer un objet vraiment immutable est plus complexe qu’il n’y paraît. La première chose concerne la définition des variables membres. A ce niveau c’est très simple : elles doivent toutes être déclarées final, ce qui oblige à ce qu’elle soient affectées lors de l’initialisation d’une instance de l’objet. L’avantage est que la JVM traite ces variables d’instance spécialement, et donc là encore on évite la nécessité d’un bloc synchronized si tant est que pour une raison ou l’autre c’était nécessaire.

De même la classe immutable doit être final car sinon des classes filles mutables pourraient en hériter, ce qui pourrait poser problème.

Ca c’était la partie facile. Maintenant considérons le code suivant :

MonObjImmutable obj = ... ;
// ...
List<String> l = obj.getList();
l.add("hello");

On observe qu’ici même si la liste de MonObjImmutable était settée lors de la construction, on peut la modifier par la suite. Dès lors il convient de s’assurer que ce genre d’opération n’est pas possible. Deux solutions ici : soit vous encapsulez les variables internes de votre objet immutable dans des conteneurs immutables comme Collections.unmodifiableList(), soit si ce n’est vraiment pas possible vous faites une copie en profondeur des variables membres. Pour ce dernier cas on peut considérer le code suivant :

MonObjImmutable obj = ... ;
// ...
List<Date> l = obj.getList();

for (Date d: l) {
   d.setTime(42L);
}

La nécessité ici que la méthode getList() retourne des copies des objets de la liste originale de obj en lieu et place de références d’objets de cette même liste paraît ici évidente.

Dernier point, lors de la construction, pensez à faire de la copie défensive. Je m’explique avec le code suivant :

List<String> l = new ArrayList<>();
// ...
MonObjImmutable obj = new MonObjImmutable(l);
l.add("hello");

Si ici il n’y a pas de copie défensive on peut parfaitement modifier le contenu de l’instance obj après que celle-ci soit initialisée, autrement dit on casse le contrat d’immutabilité.

Les cas d’utilisation

Comme on l’a vu les objets immutables sont de très bons candidats pour avoir des variables thread-safe sans efforts. Ils sont aussi nécessaires pour définir des constantes. Considérons à ce sujet le code suivant :

private final static String[] CONSTANT_ATTEMPT = {"one", "two", "three"};

Ce code n’est pas safe car on peut modifier le contenu de CONSTANT_ATTEMPT. Vous ne me croyez pas ? Essayez donc ceci :

CONSTANT_ATTEMPT[2] = "four";

La version safe de ce code serait :

private final static List<String> CONSTANT = Collections.unmodifiableList(Arrays.asList("one", "two", "three"));

Usage dans les Set et les Map

Les Set et les Map utilisent des discriminants pour accélérer la recherche. Dans le cas des Hash-collections, la méthode appelée va être hashCode, ce qui explique pourquoi on redéfinit toujours ce dernier en même temps que le equals. Dans le cas des Sorted-collections on utilise le compareTo. Dans les deux cas ce discriminant ne doit pas changer au cours du temps, sinon vous cassez le fonctionnement de la Map qui le contient. Pas convaincu ? Essayez donc le code ci-dessous :

Set<Date> set = new HashSet<>();
Date d = new Date(100000000L);
set.add(d);
System.out.println(set.contains(d)); // affiche true
d.setTime(50000L);
System.out.println(set.contains(d)); // affiche très très probablement false, dans 99.999999% des cas

La même chose pourrait s’appliquer si vous utilisiez une Map. Pour info ce point est écrit noir sur blanc dans la documentation de l’interface Map, et comme un Set n’est qu’en fait un wrapper pour la Map correspondante dans la plupart des JVM, le comportement du Set est analogue à celui d’une Map sur ce point…

L’inconvénient des objets immutables : leur potentiel usage mémoire

Les objets immutables ont plein d’avantages, mais présentent un gros défaut. Par leur nature si vous voulez une instance modifiée d’un objet immutable vous êtes obligé d’en créer une copie. Ceci peut à terme augmenter le nombre de cycles de garbage collector sur votre JVM, ce qui a dans certains cas un impact non négligeable sur les performances.

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

• #AstuceDeCode 7 : la visibilité package private en Java
• #AstuceDeCode 8 : quelques commandes sympa de la JVM
• Le fonctionnement du garbage collector

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn