Immuabilité

Un avantage de la version non immuable de la classe Date était la facilité avec laquelle on pouvait obtenir une date ressemblant à une autre en ne changeant qu'une partie des valeurs, p.ex. :

Date d = new Date(1903, 12, 28);
d.setYear(1969); // maintenant 1969-12-28

Doit-on renoncer à ce style de programmation lorsqu'on rend les dates immuables ? Non, il suffit d'ajouter des méthodes retournant une nouvelle date dérivée d'une date existante.

Dans le cas des dates immuables, on peut ainsi ajouter trois méthodes, withYear, withMonth et withDay permettant d'obtenir une nouvelle date dont tous les attributs sauf un sont égaux à ceux de la date à laquelle on l'applique :

public final class Date {
  // … comme avant
  public Date withYear(int newY) {
    return new Date(newY, m, d);
  }
  // … idem pour withMonth et withDay
}

Ces méthodes ajoutées, on peut récrire notre exemple pour obtenir quelque chose d'aussi concis qu'avec les dates non immuables :

Date d = new Date(1903, 12, 28);
Date d2 = d.withYear(1969); // 1969-12-28

L'avantage de cette version est que l'on a maintenant toujours les deux dates à disposition : d représente le 28 décembre 1903 tandis que d2 représente le 28 décembre 1969.

Il importe de ne pas confondre deux notions proches : l'immuabilité et la « non modifiabilité ». Ainsi, on dit qu'une classe est :

immuable

si ses instances ne peuvent pas changer d'état une fois créées,

non modifiable

si un morceau de code ayant accès à l'une de ses instances n'a pas la possibilité d'appeler des méthodes modifiant son état.

Dès lors, une classe immuable est toujours non modifiable, mais l'inverse n'est pas forcément vrai. Par exemple, la classe Date ci-dessous n'est pas modifiable, dans le sens où un morceau de code ayant accès à une de ses instances ne peut modifier son contenu (sauf dans certains cas en utilisant le transtypage) :

class Date {
  protected int y, m, d;
  // constructeur omis
  public int year() { return y; }
  public int month() { return m; }
  public int day() { return d; }
}
class ModifiableDate extends Date {
  public void setYear(int newY) { y = newY; }
}

Par contre, un objet ayant le type Date n'est pas forcément immuable, car il peut s'agir en réalité d'une instance de ModifiableDate.

Dans la vie réelle, du point de vue du propriétaire d'un compte en banque, le montant disponible sur ce compte est non modifiable, mais il n'est pas immuable pour autant. En effet, le propriétaire d'un compte ne peut pas directement changer le montant disponible. Par contre, ce montant change au cours du temps, en fonction des transferts d'argent effectués sur le compte.

Pour qu'une classe soit immuable, il faut qu'elle satisfasse les conditions suivantes :

• tous ses attributs sont finaux (final), initialisés lors de la construction et jamais modifiés par la suite,
• toute valeur non immuable fournie à son constructeur est copiée en profondeur avant d'être stockée dans un de ses attributs,
• aucune valeur non immuable stockée dans un de ses attributs n'est fournie à l'extérieur, p.ex. par un accesseur : soit chacune de ces valeurs non immuable est rendue non modifiable avant d'être fournie à l'extérieur, soit seule une copie profonde est fournie.

De plus, dans la plupart des cas, la classe elle-même doit être finale (final), faute de quoi il est possible de violer l'immuabilité en définissant une sous-classe non immuable.

Les conditions précitées impliquent que, s'il est facile d'écrire une classe immuable composée uniquement de valeurs immuables, les choses se compliquent lorsque des valeur non immuables entrent en jeu.

Pour écrire une classe immuable, il faut donc autant que possible se baser sur d'autres classes immuables, mais ce n'est malheureusement pas toujours possible, par exemple avec les tableaux.

Pour illustrer le concept de bâtisseur, nous allons en développer un pour la classe Date immuable présentée plus haut. La construction d'une instance de Date ne demandant que trois valeurs — le jour, le mois, l'année — la définition d'un bâtisseur n'est pas vraiment justifiée. Cela n'a toutefois que peu d'importance, les concepts présentés ci-dessous étant faciles à adapter aux cas pour lesquels un bâtisseur est véritablement utile, par exemple pour une classe de vecteurs ou de matrices immuables.

La classe d'un bâtisseur ressemble à la classe dont les instances sont à bâtir. En particulier, un bâtisseur a généralement les mêmes attributs que la classe qu'il bâtit, mais ceux-ci sont — dans la plupart des cas — modifiables.

Un bâtisseur de dates contient donc trois attributs : un pour l'année, un pour le mois, un pour le jour. A la différence des attributs de la classe Date, ceux-ci sont modifiables via des méthodes (setYear, setMonth, setDay). La valeur initiale de ces trois attributs est ici spécifiée à la construction, mais dans certains cas on peut imaginer utiliser des valeurs par défaut — p.ex. la date du jour actuel.

Finalement, la méthode build construit une instance de la classe à bâtir, ici une date.

public final class DateBuilder {
  private int y, m, d;
  public DateBuilder(int y, int m, int d) {
    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 et day/setDay

  public Date build() {
    return new Date(y, m, d);
  }
}

Ce bâtisseur peut encore être amélioré en changeant le type de retour des méthodes de modification (set…). Plutôt que de ne rien retourner, elles peuvent retourner le bâtisseur lui-même, c-à-d this. Par exemple, la méthode setYear devient alors :

public DateBuilder setYear(int y2) {
  y = y2;
  return this;
}

Cette modification permet de chaîner les appels :

Date d = new DateBuilder(1903, 12, 28)
  .setYear(1969)
  .build(); // 1969-12-28

Le bâtisseur de dates ressemble fortement à la version non immuable de Date. Ne retrouve-t-on donc pas les mêmes problèmes ?

Non, car le bâtisseur n'est utilisé que brièvement pour construire des dates, pas pour les représenter par la suite. Par exemple, la classe Person stocke une date immuable — avec tous les avantages que cela comporte — et pas un bâtisseur de date.

De manière générale, un bâtisseur n'est utilisé que très localement et n'est pas stocké dans un attribut d'une classe. De par son aspect local, une telle utilisation d'un objet non immuable ne pose pas de problème.

Les classes Date et DateBuilder développées plus haut sont intimement liées, dans le sens où la seconde n'a aucun sens sans la première. Dès lors, il serait bien de pouvoir les définir en commun, ce qui peut se faire en Java par imbrication d'une classe dans une autre.

Pour imbriquer le bâtisseur de date DateBuilder dans la classe Date, il suffit de :

• déplacer la classe DateBuilder à l'intérieur de la classe Date,
• lui attacher l'attribut static, pour en faire ce que l'on nomme une classe imbriquée statiquement,
• la renommer en Builder, le préfixe Date étant redondant suite à l'imbrication.

En effectuant les opérations susmentionnées, on obtient le résultat suivant :

public final class Date {
  // … comme avant
  public final static class Builder {
    // … comme avant
  }
}

A noter que depuis l'extérieur de la classe Date, il faut utiliser la notation pointée pour désigner la classe Builder imbriquée, en écrivant p.ex. new Date.Builder(…). C'est la raison pour laquelle nous avons renommé cette classe.

La possibilité d'imbriquer des classes en Java est utile dans d'autres cas que celui des bâtisseurs, et sera examinée plus tard dans toute sa généralité. Pour l'instant, le seul type d'imbrication qui nous intéresse est celui utilisé ci-dessus, à savoir l'imbrication dite statique.

Une classe imbriquée statiquement dans une autre est très similaire à une classe non imbriquée. Les différences principales sont :

1. de l'extérieur de la classe englobante, le nom d'une classe imbriquée statiquement est précédé de celui de sa classe englobante (Date.Builder dans notre cas),
2. une classe imbriquée statiquement a accès aux membres privés statiques (private static) de sa classe englobante, ainsi qu'à ses constructeurs privés,
3. une classe imbriquée statiquement peut être déclarée privée (private) ou protégée (protected), affectant sa visibilité depuis l'extérieur selon les règles usuelles.

Attention, une classe imbriquée statique ne peut accéder qu'aux membres statiques de sa classe englobante !

Des bâtisseurs sont parfois utilisés dans la bibliothèque Java pour faciliter la construction d'instances de classes immuables.

Un exemple important est la classe StringBuilder, un bâtisseur de chaînes de caractères. Pour mémoire, la classe Java des chaînes de caractères, String, est immuable — comme il se doit.

Le fonctionnement de la classe StringBuilder est assez similaire à celui du bâtisseur de dates décrit plus haut, si ce n'est que sa méthode de construction se nomme toString et pas build. L'extrait de programme ci-dessous illustre son utilisation :

StringBuilder b = new StringBuilder("[");
for (int i = 1; i <= 10; ++i) {
  b.append(i);
  if (i < 10)
    b.append(", ");
}
String s = b.append("]").toString();
// s vaut "[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]"

(On notera que cet exemple s'écrirait de manière encore plus simple au moyen de la classe StringJoiner, qui est un bâtisseur de chaînes spécialisé au cas où la chaîne à bâtir est composée de différentes parties séparées par une chaîne de séparation, ici la virgule. Il n'en reste pas moins que la classe StringBuilder est utile dans un grand nombre de situations.)

Sachez que lorsque vous utilisez l'opérateur + pour concaténer des chaînes en Java, le compilateur traduit automatiquement cela en une utilisation de StringBuilder. Par exemple, le code ci-dessous :

int x = …, y = …;
System.out.println("x=" + x + " y=" + y);

est automatiquement traduit en :

int x = …, y = …;
System.out.println(new StringBuilder("x=")
		   .append(x)
		   .append(" y=")
		   .append(y)
		   .toString());

En conclusion, un bâtisseur peut être une addition bienvenue à une classe immuable dans les cas où il est utile de construire des instances par étapes. La règle ci-dessous énonce cela et résume la marche à suivre pour définir un bâtisseur.