Patrons de conception II

La classe Collections de la bibliothèque Java possède la méthode statique shuffle permettant de mélanger les éléments d'une liste :

public static <E> void shuffle(List<E> list)

Est-il possible d'utiliser cette méthode pour mélanger un tableau Java ? Directement, cela n'est clairement pas possible, les tableaux n'étant pas des listes. Mais existe-t-il un moyen indirect d'y parvenir ?

Pour permettre l'utilisation d'un tableau Java là où une liste est attendue, il suffit d'écrire une classe qui adapte le tableau en le présentant comme une liste. Cette classe doit implémenter l'interface List du paquetage java.util et effectuer les opérations de cette interface directement sur le tableau qu'elle adapte. Pour simplifier sa définition, on peut en faire une sous-classe de AbstractList, une classe héritable dont le but est justement de faciliter la définition de nouveaux types de listes.

final class ArrayAdapter<E> extends AbstractList<E> {
  private final E[] array;

  public ArrayAdapter(E[] array) {
    this.array = array;
  }

  @Override
  public E get(int index) {
    return array[index];
  }

  @Override
  public E set(int index, E newValue) {
    E oldValue = array[index];
    array[index] = newValue;
    return oldValue;
  }

  @Override
  public int size() {
    return array.length;
  }
}

Une fois l'adaptateur défini, il est possible de l'utiliser pour mélanger un tableau au moyen de la méthode shuffle :

String[] array = …;
List<String> adaptedArray = new ArrayAdapter<>(array);
// mélange les éléments de array
Collections.shuffle(adaptedArray);

Le diagramme de classes ci-dessous illustre cette solution :

Notez qu'un tel adaptateur est fourni dans la bibliothèque Java par la méthode asList de Arrays. Il est donc possible de mélanger un tableau en écrivant simplement :

String[] array = …;
List<String> adaptedArray = Arrays.asList(array);
// mélange les éléments de array, via adaptedArray
Collections.shuffle(adaptedArray);

De manière générale, lorsqu'on désire utiliser une instance d'une classe donnée là où une instance d'une autre classe est attendue, il est possible d'écrire une classe servant d'adaptateur. Bien entendu, il faut que le comportement des deux classes soit relativement similaire, sans quoi l'adaptation n'a pas de sens.

Le patron de conception Adapter décrit cette solution.

Le diagramme de classes ci-dessous illustre l'adaptation au moyen d'un adaptateur Adapter d'une classe Adaptee en Target, pour le compte d'une classe cliente Client.

Le patron Adapter se rencontre très souvent en pratique, comme les quelques exemples ci-dessous l'illustrent.

Les patrons Decorator et Adapter sont très proches et l'un comme l'autre sont parfois désignés par le nom Wrapper.

La différence entre les deux est qu'un décorateur a le même type que l'objet qu'il décore, alors qu'un adaptateur a un type différent — c'est son but ! La différence peut se voir p.ex. en comparant les diagrammes de classes de InputStreamReader (un adaptateur) et de BufferedInputStream (un décorateur).

Une conséquence de cette différence est qu'il est possible d'empiler des décorateurs, mais pas des adaptateurs. Par exemple, l'extrait de code ci-dessous empile deux décorateurs (de type BufferedInputStream et GZIPInputStream) sur un flot de base de type FileInputStream.

InputStream s = new GZIPInputStream(
		  new BufferedInputStream(
		    new FileInputStream(…)));

Un tel empilement ne serait pas possible avec des adaptateurs.

Admettons que l'on désire écrire un tableur simple. Dans un tableur, une feuille de calcul est composée de cellules qui contiennent soit des nombres, soit des formules. Une formule décrit comment calculer la valeur de la cellule en fonction de la valeur d'autres cellules. L'image ci-dessous présente un tableur simple, les formules commençant par le caractère = :

Le contenu d'une cellule contenant une formule doit être mis à jour dès que le contenu d'une cellule dont elle dépend change. Dans l'exemple ci-dessus, la cellule A3 dépend des cellules A1 et A2, B3 dépend de B1 et B2, et C3 dépend de A3 et B3 — donc indirectement de A1, A2, B1 et B2.

Comment organiser le programme pour garantir que les mises à jour nécessaires soient faites ?

Une solution consiste à permettre aux cellules d'en observer d'autres. Lorsque la valeur d'une cellule change, toutes les cellules qui l'observent sont informées du changement.

Une fois cette possibilité offerte, toute cellule contenant une formule observe la ou les cellules dont elle dépend — c-à-d celles qui apparaissent dans sa formule. Lorsqu'elle est informée du changement de l'une d'entre elles, elle met à jour sa propre valeur.

Afin d'illustrer cette solution, modélisons un tableur très simple dont les cellules contiennent soit un nombre, soit une formule. Pour simplifier les choses, nos formules sont toutes des sommes de la valeur de deux autres cellules — c-à-d qu'elles ont la forme =C1+C2 où C1 et C2 sont des cellules.

Chaque fois que l'état d'un premier objet — appelé observateur — dépend de l'état d'un second objet — appelé sujet — l'observateur peut observer l'état de son sujet et se mettre à jour dès que celui-ci change. Pour que l'observation soit possible, il faut que le sujet gère l'ensemble de ses observateurs et les avertisse lors d'un changement.

C'est l'idée du patron de conception Observer.

Le gros intérêt du patron Observer est qu'il découple les sujets et les observateurs, en ce que le sujet ne sait généralement rien de ses observateurs. Pour cette raison, le patron Observer est très souvent utilisé par les bibliothèques d'interface graphique, par exemple.

Cela dit, le patron Observer possède également plusieurs inconvénients :

• il impose un style de programmation impératif (non immuable), dans lequel les objets ont un état qui change au cours du temps,
• il peut rendre les dépendances cycliques entre états difficiles à voir,
• il peut rendre observables des états qui ne devraient pas l'être (glitches).

Examinons plus en détail ces trois problèmes.

Le patron de conception Observer est très fréquemment utilisé dans les bibliothèques de gestion d'interfaces graphiques.

Les composants graphiques d'une telle application doivent souvent refléter l'état interne de l'application. Pour rester à jour, ils observent simplement la partie de l'état interne de l'application dont ils dépendent.

Par exemple, un composant affichant un graphique dans un tableur peut observer les données qu'il représente pour savoir quand se mettre à jour.

Une application graphique typique est composée d'un certain nombre de composants standards (boutons, menus, listes, etc.) qui permettent à l'utilisateur de visualiser et de manipuler l'état de l'application.

Comment faire en sorte que les composants n'aient aucune connaissance précise de l'application et soient ainsi réutilisables ?

La solution (évidente) à ce problème consiste à découpler la gestion de l'interface utilisateur de la gestion de l'état propre à l'application.

Le découplage entre la gestion de l'interface utilisateur et la logique propre à l'application peut se faire de différentes manières. Le patron Model-View-Controller (MVC) propose d'organiser le code du programme en trois catégories :

1. le modèle, qui contient la totalité du code propre à l'application et qui n'a aucune notion d'interface graphique,
2. la vue, qui contient la totalité du code permettant de représenter le modèle à l'écran,
3. le contrôleur, qui contient la totalité du code gérant les entrées de l'utilisateur et les modifications du modèle correspondantes.

Cette organisation et les interactions qu'elle implique avec l'utilisateur sont illustrées dans la figure ci-dessous :

Notez que le patron MVC n'est pas au même niveau que les autres patrons que nous avons vus jusqu'à présent. En effet, il propose une organisation de la totalité du programme, pas seulement d'une petite partie de celui-ci pour résoudre un problème local. Pour cette raison, MVC est parfois qualifié de patron architectural (architectural pattern).

Le patron Observer joue un rôle central dans la mise en œuvre du patron MVC. Par exemple, pour que le modèle puisse être découplé de la vue, il faut que cette dernière ait la possibilité de réagir aux changements de ce premier. Cela se fait généralement au moyen du patron Observer.

Le patron MVC a plusieurs avantages :

• le modèle peut être réutilisé avec différentes interfaces utilisateur (p.ex. application de bureau, application Web, application mobile),
• le modèle est relativement facile à tester puisqu'il n'est absolument pas lié à une interface graphique,
• le code gérant les composants graphiques standards (boutons, menus, etc.) est réutilisable pour de nombreuses applications.

Ces avantages proviennent principalement de la séparation entre le modèle et le couple (vue, contrôleur). En pratique, il est d'ailleurs souvent difficile de découpler la vue du contrôleur, et cela n'est donc que partiellement fait, voire pas du tout.

De nombreuses bibliothèques d'interface utilisateur graphique utilisent le patron MVC ou l'un de ses dérivés, p.ex. :

• Swing utilise une variante de MVC dans laquelle la vue et le contrôleur ne font souvent qu'un,
• Cocoa — la bibliothèque graphique de macOS — utilise le patron MVC,
• beaucoup de bibliothèques de gestion d'interface graphique pour les applications Web sont basées sur MVC,
• etc.