Patrons de conception (1)

L'intérêt des patrons de conception est qu'ils permettent de diffuser largement les meilleures solutions connues à différents problèmes récurrents. De plus, ces solutions sont nommées, ce qui permet de raisonner et de communiquer à un plus haut niveau d’abstraction que lorsqu’on se concentre sur les détails de mise en œuvre.

Cela dit, et malgré leur popularité, les patrons de conception ne sont pas une panacée. Une utilisation systématique des patrons ne saurait garantir qu’un programme soit bien conçu. Il est donc important de n’utiliser un patron que lorsque cela est justifié, et que les avantages liés à son utilisation compensent les inconvénients — p.ex. l’augmentation de la complexité du programme qui peut en résulter.

Un patron de conception décrit comment écrire et organiser un ensemble de classes pour résoudre un problème donné, et non pas un ensemble de classes concrètes. Dès lors, un patron ne peut pas être écrit une fois pour toutes et inclu dans une bibliothèque. Au lieu de cela, c'est à la personne écrivant un programme que revient la responsabilité d'appliquer le patron en écrivant les classes correspondantes. Par exemple, le concept de bâtisseur est un patron de conception — nommé Builder — qui doit être appliqué pour chaque classe pour laquelle un bâtisseur doit être fourni.

Un patron de conception n’est normalement pas lié à un langage de programmation donné. Toutefois, beaucoup d'entre eux ont été inventés dans le contexte de langages orienté-objets. Ils font une utilisation intensive des concepts de ce type de langages — classes, objets, polymorphisme d’inclusion, etc. — et sont donc difficilement utilisables tels quels dans d’autres contextes.

Il faut aussi noter que certains langages possèdent des concepts qui rendent certains patrons obsolètes. Par exemple, les langages fonctionnels comme Scala possèdent le filtrage de motifs (pattern matching) qui rend l'utilisation du patron Visitor inutile.

Un diagramme de classes décrit visuellement un ensemble de classes ou interfaces et leurs relations, qui peuvent être de différente nature :

• héritage : lorsqu'une classe hérite d'une autre ou implémente une interface,
• association : lorsqu'une classe utilise une ou plusieurs instances d'une autre classe,
• instanciation : lorsqu'une classe créée des instances d'une autre classe.

Les relations d'association sont annotées avec leur nom et leur arité. Cette dernière — un entier strictement positif ou * pour indiquer une valeur arbitraire — donne le nombre d'objets liés par l'association.

Le diagramme de classes annoté ci-dessous introduit la notation utilisée au moyen d'un ensemble de classes et interfaces faisant partie d'un jeu de Monopoly.

En pratique, dans cet exemple, players sera un attribut de Game, d'un type collection quelconque, p.ex. une liste.

Etant donné que les patrons décrivent une manière d'organiser un ensemble de classes — et pas un ensemble de classes réel — les diagrammes les illustrant utilisent des classes fictives signalées par des bords discontinus, dont le nom évoque généralement le rôle. Le diagramme ci-dessous est un exemple qui pourrait être utilisé dans la description du patron Builder.

Admettons que l'on désire écrire une bibliothèque de calcul matriciel. Un composant central d'une telle bibliothèque est la (ou les) classe(s) modélisant les matrices.

Comme toutes les classes représentant des entités mathématiques, ces classes devraient être immuables. Cela implique que la totalité des éléments d'une matrice doivent être spécifiés lors de sa construction. Pour les grosses matrices, ou les matrices creuses, cela peut s'avérer pénible.

Comment résoudre ce problème ?

Une solution consiste à offrir un bâtisseur de matrice, c'est-à-dire une classe représentant une matrice en cours de construction. Le bâtisseur est modifiable, et possède des méthodes pour changer les différents éléments de la matrice en cours de construction. Il possède également une méthode pour construire la matrice.

Par exemple, en admettant que les matrices soient représentées par une interface et deux classes de mise en œuvre concrètes :

public interface Matrix {
  double get(int r, int c);
  Matrix transpose();
  Matrix inverse();
  Matrix add(Matrix that);
  Matrix multiply(double that);
  Matrix multiply(Matrix that);
  // … autres méthodes
}
public final class DenseMatrix
  implements Matrix { … }
public final class SparseMatrix
  implements Matrix { … }

un bâtisseur de matrice pourrait ressembler à ceci :

public final class MatrixBuilder {
  private double[][] elements;
  public MatrixBuilder(int r, int c) {
    elements = new double[r][c];
  }
  public double get(int r, int c) {
    return elements[r][c];
  }
  public void set(int r, int c, double v) {
    elements[r][c] = v;
  }
  public Matrix build() {
    return new DenseMatrix(elements);
  }
}

Outre le fait que ce bâtisseur permet de construire une matrice en plusieurs étapes, il permet également de choisir une représentation pour la matrice qui soit appropriée à son contenu !

Par exemple, une matrice creuse — c-à-d dont la plupart des éléments valent 0 — peut être représentée au moyen d'une table associative contenant les éléments non-nuls. Une matrice dense peut être représentée par un tableau bi-dimensionnel. Le choix entre les deux représentations peut être fait par le bâtisseur au moment de la création de la matrice :

public final class MatrixBuilder {
  // … comme avant
  public Matrix build() {
    if (density() > 0.5)
      return new DenseMatrix(elements);
    else
      return new SparseMatrix(elements);
  }
}

Le diagramme de classes ci-dessous montre les classes impliquées dans la construction, par une classe Main, d'une matrice, au moyen de ce bâtisseur.

Chaque fois que le processus de construction d'une classe est assez difficile pour que l'on désire le découper en plusieurs étapes, on peut utiliser un objet pour stocker l'état de l'objet en cours de construction.

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

Le diagramme de classes ci-dessous illustre les classes (fictives) impliquées dans la construction d'une instance de la classe Product par une instance d'une classe Director, au moyen d'un bâtisseur de classe ConcreteBuilder.

La classe String (de java.lang) modélise les chaînes de caractères, qui ne sont pas modifiables.

La classe StringBuilder sert de bâtisseur pour les chaînes de caractères. Elle possède entre autres une méthode append pour ajouter la représentation textuelle d'un objet à la chaîne en cours de construction, et la méthode toString pour obtenir la chaîne construite.

Admettons que l'on désire écrire un programme de dessin vectoriel 2D, permettant de dessiner et manipuler différentes formes géométriques. Celles-ci sont représentées par une interface Shape et plusieurs mises en œuvre, une pour chaque forme de base.

public interface Shape {
  public boolean contains(Point p);
  // … autres méthodes
}
public final class Circle implements Shape {
  …
}
// … Polygon, etc.

On désire offrir la possibilité d'appliquer différentes transformations géométriques aux formes de base : translation, rotation, symétrie, etc. Comment faire ?

Une solution consiste à définir des pseudo-formes qui en transforment d'autres. Par exemple pour la translation :

public final class Translated implements Shape {
  private final Shape shape;
  private final double dx, dy;
  public Translated(…) { … }
  public boolean contains(Point p) {
    return s.contains(new Point(p.x() - dx, p.y() - dy));
  }
  // … autres méthodes
}

Le diagramme de classes ci-dessous montre les classes impliquées dans cet exemple.

Chaque fois que l’on désire changer le comportement d’un objet sans changer son interface, on peut « l’emballer » dans un objet ayant la même interface mais un comportement différent. L’objet « emballant » laisse l’objet emballé faire le gros du travail, mais modifie son comportement lorsque cela est nécessaire.

Cette solution est décrite par le patron Decorator, aussi souvent appelé Wrapper.

Le patron Decorator se rencontre très fréquemment en pratique, comme les quelques exemples ci-dessous l'illustrent.

Le patron Decorator permet de modifier le comportement d'une classe existante, tout comme l'héritage. Il est intéressant de comparer ces deux solutions sur un exemple concret. Pour ce faire, admettons que l'on désire ajouter à un ensemble HashSet la possibilité de compter le nombre total d'éléments ajoutés.

De manière générale, une classe ne peut jouer correctement qu'un seul des deux rôles suivants :

1. celui de créatrice d'objets,
2. celui de classe mère.

Malheureusement, les langages actuels ne permettent pas de faire clairement la différence entre ces deux rôles. De plus, par défaut toute classe peut jouer les deux rôles et c'est au programmeur d'interdire explicitement l'un ou l'autre usage, ce qu'il ne fait généralement pas. En pratique, il est toutefois très utile de distinguer clairement deux types de classes correspondant aux rôles ci-dessus :

1. Une classe instantiable est une classe dont le (seul) rôle est de permettre la création d'objets. Pour empêcher son utilisation dans le rôle de super-classe, il est conseillé d'empêcher la définition de sous-classes en la déclarant finale.
2. Une classe héritable est une classe dont le (seul) rôle est de servir de super-classe. Pour empêcher son utilisation en tant que productrice d'objets, il est conseillé de la déclarer abstraite, même si elle ne l'est pas réellement, c-à-d même si elle ne possède pas de méthode abstraite. C'est p.ex. ce qui a été fait avec ForwardingSet.

La documentation d'une classe héritable doit être bien plus détaillée que celle d'une classe instantiable, et décrire tous les aspects de sa mise en œuvre susceptibles d'influencer le comportement des sous-classes, p.ex. le fait qu'une méthode en utilise une autre.

Les collections Java sont un exemple réel de hiérarchie dans laquelle la distinction entre ces différents types de classes est relativement bien faite. Par exemple, la hiérarchie liée à la classe ArrayList est illustrée ci-dessous :

Dans cette hiérarchie, les classes AbstractCollection et AbstractList sont héritables et fournissent des mises en œuvre par défaut de la plupart des méthodes de Collection ou List. La classe ArrayList, quant à elle, est instanciable et représente la mise en œuvre des listes au moyen d'un tableau « redimensionnable ». Malheureusement, elle n'est pas finale, erreur historique qu'il est difficile de corriger actuellement pour des raisons de compatibilité.

On désire améliorer le programme de dessin vectoriel 2D pour offrir à l'utilisateur la possibilité de grouper plusieurs formes. Bien entendu, un groupe doit se comporter comme une forme normale, à laquelle il est possible d'appliquer des transformation, ou qu'il est possible de placer dans un groupe plus grand. Comment faire ?

Une solution consiste à définir une pseudo-forme qui représente un groupe :

public final class Group implements Shape {
  private final List<Shape> shapes;
  public Group(List<Shape> shapes) { … }
  public boolean contains(Point p) {
    for (Shape s: shapes)
      if (s.contains(p))
        return true;
    return false;
  }
  // … autres méthodes
}

Les classes impliquées dans cet exemple sont représentée dans le diagramme de classes ci-dessous :

Lorsque les objets d'un programme peuvent être composés entre eux pour former des macro-objets, il est judicieux de faire en sorte que ceux-ci aient le même type que les objets qu'ils composent. De la sorte, il est possible de traiter les objets et les macro-objets de manière uniforme.

Cela implique entre autres que les macro-objets peuvent être composés d'autre macro-objets, de manière récursive.

Cette idée est décrite par le patron Composite.