Immuabilité

Lors de la conception d'une classe, la question se pose de savoir si celle-ci doit être immuable ou non. Une classe est dite immuable si l'état de ses instances ne peut pas changer après leur création.

A première vue, définir des classes immuables peut sembler inutilement restrictif. Toutefois, comme nous le verrons, ces classes permettent d'éviter plusieurs problèmes affectant les classes non immuables, et sont donc généralement préférables.

Ces problèmes sont illustrés ci-dessous au moyen d'une classe très simple permettant de représenter une date du calendrier grégorien.

Une classe (non immuable) représentant une date du calendrier grégorien pourrait s'écrire ainsi :

public final class Date {
  private int y, m, d;          // année, mois, jour
  public Date(int y, int m, int d) {
    // … vérification des arguments omise
    this.y = y; this.m = m; this.d = d;
  }
  public int year() { return y; }
  public void setYear(int y2) { y = y2; }
  // … idem pour month/setMonth, day/setDay
  @Override
  public String toString() {
    return y + "-" + m + "-" + d;
  }
}

Cette classe n'est clairement pas immuable, puisque la valeur de ses attributs y, m et d peut être changée au moyen des méthodes setYear, setMonth et setDay.

La classe Date écrite, on peut l'utiliser pour en écrire une autre représentant une personne, ayant pour attributs un nom et une date de naissance :

public final class Person {
  private final String name;    // nom complet
  private final Date birthdate; // date de naissance
  public Person(String name, Date birthdate) {
    this.name = name;
    this.birthdate = birthdate;
  }
  public String name() { return name; }
  public Date birthdate() { return birthdate; }
}

Les classes Date et Person terminées, on peut les utiliser pour écrire le programme suivant :

Date d = new Date(1903, 12, 28);
Person j = new Person("John Von Neumann", d);
d.setYear(1969);
Person l = new Person("Linus Torvalds", d);

System.out.println(j.name() + ", né le " + j.birthdate());
System.out.println(l.name() + ", né le " + l.birthdate());

On pourrait s'attendre à ce que ce programme affiche :

John Von Neumann, né le 1903-12-28
Linus Torvalds, né le 1969-12-28

Or, étonnamment, il affiche que John Von Neumann et Linus Torvalds sont tous deux nés le 28 décembre 1969. Pourquoi ? Car l'appel à setYear modifie la date de naissance stockée dans l'objet représentant John Von Neumann.

Pour corriger ce problème, étant donné que la classe Date n'est pas immuable, il faut impérativement copier la date reçue dans le constructeur de Person avant de la stocker dans l'attribut birthdate. Une telle copie est appelée copie défensive (defensive copy) car son but est de se défendre contre les éventuelles modifications que pourrait subir l'objet que l'on stocke.

Avant de pouvoir corriger le problème, il faut commencer par ajouter à la classe Date un moyen de copier une date. Cela peut se faire soit via l'implémentation de la méthode clone, soit via un constructeur de copie, solution adoptée ici :

public final class Date {
  // … comme avant
  public Date(Date that) {
    this(that.y, that.m, that.d);
  }
}

Le constructeur de copie ajouté, on peut corriger le constructeur de la classe Person afin qu'il stocke une copie de la date de naissance reçue :

public final class Person {
  // … comme avant
  public Person(String name, Date birthdate) {
    this.name = name;
    this.birthdate = new Date(birthdate);
  }
}

La classe Person est-elle désormais correcte ? Malheureusement non.

Pour le constater, posons-nous la question de savoir ce qu'affiche la variante suivante du programme présenté plus haut :

Date d = new Date(1903, 12, 28);
Person j = new Person("John Von Neumann", d);
Date b = j.birthdate();
b.setYear(1969);
Person l = new Person("Linus Torvalds", b);

System.out.println(j.name() + ", né le " + j.birthdate());
System.out.println(l.name() + ", né le " + l.birthdate());

Malheureusement, une fois encore, elle affiche que John Von Neumann et Linus Torvalds sont tous deux nés en 1969. Pourquoi ? Car l'appel à setYear modifie une fois encore la date de naissance de John Von Neumann, mais pour une raison différente de la précédente. Cette fois-ci, le problème est que la méthode birthdate retourne la date de naissance stockée en interne par la classe Person, ce qui permet à un client de modifier celle-ci. Cela n'est clairement pas souhaitable : il y a faille d'encapsulation.

Pour corriger cette faille, il faut également faire une copie défensive dans la méthode birthdate afin de retourner une copie de la date de naissance :

public final class Person {
  // … comme avant
  public Date birthdate() {
    return new Date(birthdate);
  }
}

Devoir faire ces copies défensives est problématique pour deux raisons :

1. elles doivent être faites par tous les utilisateurs de la classe non immuable,
2. il est très facile de les oublier, et les problèmes posés par de tels oublis — données corrompues, principalement — sont difficiles à diagnostiquer.

Il est donc préférable d'éviter totalement ces problèmes en définissant, autant que possible, des classes immuables.

Pour rendre la classe Date immuable, il convient de la modifier ainsi :

• les attributs y, m et d deviennent finaux (final),
• les méthodes de modification de ces attributs (setYear, setMonth, setDay) sont supprimées,
• le constructeur de copie, devenu inutile, est supprimé.

Ces modifications faites, on obtient :

public final class Date {
  private final int y, m, d;    // année, mois, jour
  public Date(int y, int m, int d) {
    // … vérification des arguments omise
    this.y = y; this.m = m; this.d = d;
  }
  public int year() { return y; }
  public int month() { return m; }
  public int day() { return d; }
}

Les dates étant maintenant immuables, les copies défensives faites dans le constructeur et dans la méthode birthdate de Person deviennent inutiles et peuvent être supprimées.

Comparées aux classes qui ne le sont pas, les classes immuables ont de nombreux avantages :

• il est facile de raisonner à leur sujet, l'état de leurs instances ne changeant jamais au cours de leur vie,
• il n'est jamais nécessaire de faire des copies défensives de leurs instances — copies qu'il est facile d'oublier,
• plus généralement, il n'est jamais nécessaire de copier leurs instances, donc elle ne nécessitent ni méthode clone, ni constructeur de copie,
• elles peuvent être partagées entre plusieurs fils d'exécution (threads) dans les applications concurrentes.

Malgré leurs nombreux avantages, les classes immuables ne sont pas totalement dénuées de défauts :

• lorsqu'une classe immuable est utilisée pour représenter une valeur qui change très souvent, le fait de devoir créer une nouvelle instance à chaque changement peut nuire aux performances,
• lorsqu'il faut effectivement que le changement d'état d'un objet soit visible à tous les possesseurs d'une référence vers cet objet, le fait que celui-ci ne soit pas immuable peut simplifier la programmation.

En pratique, malgré ces inconvénients, il reste préférable d'utiliser des classes immuables autant que possible.

Notez que ce n'est que récemment que l'utilisation de données immuables est devenue réaliste en programmation, entre autres car rapidité des processeurs modernes permet de compenser les pertes de performances que peut induire l'immuabilité. Par conséquent, les bibliothèques « anciennes » — à commencer par celle de Java — comportent souvent un grand nombre de classes non immuables. Ne les prenez pas comme modèle ! Par exemple, la classe java.util.Date est terriblement mal conçue, entre autres car elle n'est pas immuable.

Comme vous l'aurez peut-être constaté, les avantages d'une approche immuable (aussi appelée « non destructive ») commencent à être reconnus dans d'autres domaines que la programmation. Par exemple, les logiciels de retouche d'image récents comme Lightroom d'Adobe ou Photos d'Apple ne modifient pas l'image existante mais en produisent une nouvelle, contrairement à des logiciels plus anciens comme Photoshop. Il en va de même des bases de données récentes comme Datomic, qui ne modifie jamais les données qu'elle stocke contrairement à ses ancêtres (MySQL, PostgreSQL, etc.)

Un tableau Java « normal » (c-à-d pas un tableau dynamique de type ArrayList) est toujours modifiable. Dès lors, l'utilisation d'un tableau dans une classe immuable complique celle-ci, qui doit faire des copies défensives des tableaux qu'elle reçoit de l'extérieur avant de les stocker, et faire des copies défensives de ses tableaux internes avant de les fournir à l'extérieur.

Avec les tableaux dynamiques, une solution plus simple et moins coûteuse existe. La méthode unmodifiableList de la classe java.util.Collections permet d'obtenir une version non modifiable d'un tableau dynamique, dont toutes les méthodes de modification lèvent l'exception UnsupportedOperationException. Exemple :

ArrayList<String> m = new ArrayList<String>();
m.add("un"); m.add("deux"); m.add("trois");
List<String> u = Collections.unmodifiableList(m);
u.add("quatre"); // lève UnsupportedOperationException

La méthode unmodifiableList constitue le moyen le plus simple de définir une classe immuable utilisant un tableau. Une telle classe s'écrit ainsi :

• les tableaux reçus à la construction sont copiés défensivement, rendus non modifiables au moyen de la méthode unmodifiableList puis stockés ainsi dans des attributs,
• ces tableaux non modifiables sont directement retournés par les méthodes d'accès.

Notez que unmodifiableList retourne une valeur de type List et pas ArrayList.

Une classe représentant un vecteur immuable pourrait p.ex. s'écrire ainsi :

import java.util.Collections;
import static Collections.unmodifiableList;

public final class Vector {
  private final List<Double> v;
  public Vector(List<Double> a) {
    v = unmodifiableList(new ArrayList<Double>(a));
  }
  public List<Double> asList() {
    return v;
  }
}

Par définition, pour créer une instance d'une classe immuable, il faut spécifier la valeur de tous ses attributs. Ainsi, pour créer un vecteur immuable, il faut spécifier la valeur de tous ses éléments. Parfois, le fait de devoir spécifier la totalité des attributs est peu agréable. Par exemple, lorsqu'on lit les éléments d'un vecteur un à un depuis un fichier, il est plus simple de les ajouter un à un au vecteur plutôt que de les accumuler dans un tableau puis de créer un vecteur à partir de celui-ci. Faut-il dès lors abandonner l'immuabilité pour faciliter la construction par étapes d'instances ?

Plutôt que d'abandonner l'idée d'avoir des classes immuables uniquement pour faciliter leur construction par étapes, il est plus judicieux d'offrir une classe séparée, non immuable, dont le seul but est de permettre la construction progressive d'instances d'une classe immuable. Une telle classe s'appelle un bâtisseur (builder).

• Effective Java (3rd ed.) de Joshua Bloch, en particulier :
  • la règle 17, Minimize mutability sur l'intérêt des classes immuables.