De l'importance des constantes dans le modèle OO

L'importance des constantes est une chose qu'on enseigne habituellement aux étudiantes et aux étudiants en informatique lors des tout premiers cours de programmation et à laquelle trop de gens (certains enseignants inclus) n'offrent pas suffisamment de considération.

L'argument traditionnel pour utiliser des constantes se détaille à peu près comme suit :

• Elles clarifient le code. Ceci est utilisé pour indiquer aux étudiantes et aux étudiants en début de formation que le littéral 9 peut avoir plusieurs sens dans un programme (nombre d'individus dans un groupe, carré de trois, prix d'une pizza, ...) alors que NB_PLANETES a un sens beaucoup plus clair et univoque
• Elles facilitent l'entretien du code. Dans le cas d'un programme traitant du système solaire par exemple, avec le retrait de Pluton de la liste des planètes du système solaire en 2006, il aurait fallu traverser le code d'un programme utilisant le littéral 9 pour examiner chaque occurrence de ce littéral et évaluer si ce 9 signifie le nombre de planètes (chose longue et sujette à erreur) alors que si la constante symbolique NB_PLANETES avait été utilisée, il aurait suffi de changer sa valeur et de retoucher les structures de données qui en dépendent
• Elles constituent une forme de documentation par déclaration d'intention. Savoir qu'une donnée est constante constitue une forme d'information pertinente pour les programmeurs et aide à leur compréhension des algorithmes. Après tout, quoi de plus suspect que de rencontrer une donnée susceptible d'être constante et de constater qu'il s'agit d'une variable. La question se pose alors : pourquoi?
• Elles donnent des garanties d'invariance. Savoir que PI est une constante plutôt qu'une variable permet de se fier à sa valeur, qui ne sera pas modifiée de manière hostile ou par inadvertance dans le programme; par conséquent...
• Elles permettent à un compilateur de générer du meilleur code. Bien que les compilateurs ne procèdent pas tous aux mêmes optimisations et bien que certains négligent certaines opportunités d'optimisation a priori évidentes, il reste que plus un compilateur possède d'information (pertinente) sur un programme et meilleures sont ses chances de générer du code de qualité. Savoir qu'une donnée est constante permet au compilateur de procéder à certaines optimisations plus agressives que sur des variables puisque le fruit de certains tests faites sur cette donnée (par exemple est-elle négative?) sont susceptibles d'être soit toujours vrais, soit toujours faux. Sachant cela, même s'il est possible que votre compilateur ne profite pas toujours à plein de l'information quant à la constance d'une donnée, il n'y a pas de raison de ne pas lui donner l'opportunité de le faire

int f(int n) {
   int cumul = 0;
   for (int i = 0; i < n; ++i)
      if (i % 2 == 0)
         cumul += i;
   return cumul;
}

En général, si une entité peut être qualifiée constante, alors elle devrait probablement l'être. On peut ne rien gagner, mais il est pratiquement certain qu'on n'y perdra rien. C'est là une maxime fort utile à retenir, mais une maxime sans compréhension est d'une utilité limitée. Il y a beaucoup d'autres raisons pour avoir recours aux constantes, en particulier dans un monde OO, et c'est sur ces cas fort intéressants que nous poserons notre regard ici.

Définition de l'encapsulation

Ma définition de l'encapsulation dépasse le seuil des mots privé, protégé et public qu'on retrouve dans la plupart des langages de programmation OO et se situe à un niveau plus philosophique. Elle se décline en deux temps :

• un objet doit être responsable de son intégrité du début à la fin de sa vie (ceci pourrait s'exprimer de manière plus savante en disant qu'un objet doit pouvoir garantir ses invariants); et (corollaire)
• un objet doit être capable de faire en sorte de nettoyer les traces de son passage dans un système. Ses effets secondaires[0] doivent être délibérés et il ne doit pas entraîner de fuites de ressources.

Contrairement à ce que les gens pensent souvent, il est très difficile d'assurer le respect du principe d'encapsulation exprimé en ces termes en Java et dans les langages .NET, du moins sans que le code client de l'objet ne soutienne activement l'objet lui-même (en C#, par un bloc using appliqué à une classe implémentation l'interface IDisposable; en Java, du moins à partir de Java 7, dans une variante du bloc try).

La clause sur les effets de bord y est difficile à mettre en place malgré (ou même à cause de) la présence d'un moteur de collecte automatique d'ordures, comme le démontre cet article. Le problème est que Java n'offre aucune garantie d'appel à la méthode de nettoyage finalize() (elle n'est souvent pas appelée du tout) et que les langages .NET invoquent Dispose() ou son équivalent mais sans qu'aucune référence .NET dans l'objet en cours de nettoyage ne puisse être considérée valide.

Intégrer ces langages à toute ressource externe exige la mise en place de schémas de conception (IDisposable sous .NET) et l'insertion de code pour libérer les ressources manuellement, comme par exemple appeler close() sur les fichiers ou insérer des blocs finally dans le traitement d'exceptions.

Ces reliquats d'une époque pré-OO sont la conséquence directe de la collecte d'ordures prise en charge, qui doit fonctionner même quand deux objets se réfèrent mutuellement l'un et l'autre: il s'agit de l'inverse d'une médaille a priori fort jolie, qui nous rappelle qu'il n'y a rien de gratuit et que ce qui semble simplifier le code dans certains cas devient, à l'inverse, un cauchemar d'entretien dans le monde intégré et interopérable vers lequel nous tendons au moment d'écrire ceci. Prudence : la collecte automatique d'ordures n'est pas en soi une mauvaise chose. Elle règle des problèmes et permet certains styles de programmation mais ce n'est pas une panacée.

La principale cause de l'incapacité d'implémenter l'encapsulation au sens des garanties d'intégrité en Java et dans les langages .NET tient quant à elle de l'incapacité d'exprimer des constantes dans ces langages. C'est ce que nous démontrerons ici, en apportant les nuances qui s'imposent pour les classes immuables et en expliquant le prix à payer pour faire du code robuste sans avoir accès à la possibilité d'exprimer quelque chose d'aussi fondamental que des constantes.

Cas d'espèce : un rectangle ayant une position

Imaginons une classe Rectangle offrant un ensemble de services, en particulier celui permettant à un Rectangle de se dessiner. Certains choix d'implémentation doivent être faits mais ne devraient pas affecter l'interface par laquelle un Rectangle est utilisé – par exemple, si un Rectangle offre des services permettant d'en connaître la hauteur et la largeur, il importe peu pour un client du Rectangle de savoir si ces données sont calculées à partir des coordonnées de deux coins opposés du Rectangle ou si elles sont entreposées sous forme d'attributs.

Nous débuterons notre discussion en présumant les services suivants pour la classe Rectangle. Notez que même l'acte d'établir une liste de services est un geste politique dont la portée est sujette à discussion (certains choix de services proposés ci-dessous sont porteurs de conséquences distinctes selon les langages).

Portez une attention particulière à la colonne Peut modifier l'objet. Elle indique s'il est raisonnable d'accepter que l'invocation de cette méthode provoque une modification à l'état de l'objet qui en est propriétaire. Certains cas peuvent sembler évidents, mais la situation, dans son ensemble, est plus subtile qu'il n'y paraît.

Vision C++ – constantes sur une base instance

Un exemple de code C++ couvrant les diverses opérations proposées pour la classe Rectangle ci-dessus serait le suivant.

//
// Rectangle.h
//
#include <iosfwd>
class HauteurIncorrecte {};
class LargeurIncorrecte {};
class Rectangle {
public:
   // type interne public
   using size_type = short;
private:
   // une implémentation possible (parmi plusieurs)
   size_type hauteur_,
            largeur_;
   enum : size_type {
      LARGEUR_MIN =  1, HAUTEUR_MIN =  1,
      LARGEUR_MAX = 80, HAUTEUR_MAX = 24,
      LARGEUR_DEFAUT = 5, HAUTEUR_DEFAUT = 3,
   };
   static bool est_hauteur_valide(size_type hauteur) {
      return HAUTEUR_MIN <= hauteur && hauteur <= HAUTEUR_MAX;
   }
   static bool est_largeur_valide (size_type largeur) {
      return LARGEUR_MIN <= largeur && largeur <= LARGEUR_MAX;
   }
   static size_type valider_hauteur(size_type valeur) {
      return !est_hauteur_valide(valeur)? throw HauteurIncorrecte{} : valeur;
   }
   static size_type valider_largeur(size_type valeur) {
      return !est_largeur_valide(valeur)? throw LargeurIncorrecte{} : valeur;
   }
public:
   Rectangle() : largeur_{LARGEUR_DEFAUT}, hauteur_{HAUTEUR_DEFAUT} {
   }
   Rectangle(size_type hauteur, size_type largeur)
      : hauteur_{valider_hauteur(hauteur)}, largeur_{valider_largeur(largeur)}
   {
   }
   //
   // Sainte-Trinité : implicite
   //
   // accesseurs publics -- interface de consultation
   // accesseurs de premier ordre
   size_type largeur() const noexcept
      { return largeur_; }
   size_type hauteur() const noexcept {
      return hauteur_;
   }
   // accesseurs de second ordre
   size_type perimetre() const noexcept {
      return 2 * (largeur() + hauteur());
   }
   size_type surface () const noexcept {
      return largeur() * hauteur();
   }
   // méthode de projection à la console
   void dessiner() const;
   //
   // ...plusieurs autres méthodes (laissez-vous aller)...
   //
};
// projection sur un flux arbitraire
std::ostream& operator<<(std::ostream&, const Rectangle&);

//
// Rectangle.cpp
//
#include "Rectangle.h"
#include <iostream>
using namespace std;
void Rectangle::dessiner() const {
   cout << *this;
}
ostream& operator<<(ostream &os, const Rectangle &r) {
   using size_type = Rectangle::size_type;
   for (size_type i = 0; i < r.hauteur(); ++i) {
      for (size_type j = 0; j < r.largeur(); ++j)
         os << '*';
      os << endl;
   }
   return os;
}

Remarquez la présence dans ce code de garanties de constance. Ces garanties sont indiquées par la présence du mot clé const, qui sert à plusieurs sauces mais dans une optique précise :

• Placé devant le type d'un objet (incluant les données de types primitifs), incluant le cas où l'objet est un paramètre à un sous-programme, ce mot indique que le compilateur doit interdire toute tentative de modification sur cet objet (hormis au moment de sa construction et de sa destruction), incluant utiliser l'objet à gauche d'une affectation, passer l'objet de manière indirecte (par référence ou par adresse) à tout sous-programme ne garantissant pas qu'il restera intact ou encore invoquer toute méthode de cet objet qui ne se porte pas elle-même garante de l'intégrité de l'objet
• Placé suite à la parenthèse fermante de la liste des paramètres d'une méthode d'instance, ce mot indique que la méthode garantit ne pas changer l'état de l'instance à laquelle elle appartient. Concrètement, const placé après la parenthèse fermante d'une méthode d'instance s'applique à this pour la durée de l'exécution de cette méthode
• Conséquemment, la qualification const sur une méthode n'a de sens que pour une méthode d'instance (qui a un this), pas pour une fonction globale ou une méthode de classe (qualifiée static)

Impact de la constance pour un objet

Sachant quelles sont ces quelques règles, il devient clair qu'un objet constant est un objet sur lequel on ne peut réaliser que des opérations garantissant la non modification de ses états.

#include "Rectangle.h"
void f(Rectangle &);
void g(const Rectangle &);
int main() {
   const Rectangle r0{3, 9};
   Rectangle r1 = r0;
   f(r0); // illégal!
   f(r1); // ok
   g(r0); // ok
   g(r1); // ok
   r0 = r1; // illégal
   r0.dessiner(); // ok, dessiner() est const
   r1.dessiner(); // ok
}

Examinons maintenant le cas où un Rectangle sert en tant qu'attribut dans une autre classe.

#include "Rectangle.h"
class Bouton {
   // ...
   Rectangle dimension_;
   // ...
public:
   // ...
   Rectangle dimension() const {
      return dimension_;
   }
   // ...
};

La méthode dimension() de la classe Bouton y est légitimement marquée const du fait qu'elle retourne une copie du Rectangle représentant la dimension d'un bouton, chose inoffensive pour le Bouton.

Imaginons maintenant que, pour quelque raison que ce soit, l'opération de copie d'un Rectangle soit jugée coûteuse (par exemple parce que la masse d'information dans un Rectangle se soit accrue au fil du temps). On voudra peut-être alors éviter de copier un Rectangle à chaque invocation de dimension() puisque cela implique solliciter un constructeur par copie et un destructeur à chaque fois pour la variable temporaire retournée par la méthode.

#include "Rectangle.h"
class Bouton {
   // ...
   Rectangle dimension_;
   // ...
public:
   // ...
   Rectangle& dimension() {
      return dimension_;
   }
   // ...
};

En effet, si l'état du Bouton peut changer à son insu, le Bouton ne peut plus être considéré responsable de sa propre intégrité et, par conséquent, ce Bouton devient vulnérable. Tout appelant hostile pouvant le détruire de l'intérieur; l'intégrité d'un Bouton ne peut plus être garantie. Notez que même si la référence sur un Rectangle retournée par la méthode demeurera une référence sur un Rectangle valide en tant que Rectangle, il est possible que les politiques de validité d'une dimension de Bouton soient plus strictes que celles assurant la validité d'un Rectangle; priver le Bouton de la capacité d'assurer son intégrité est une faute grave même si certaines règles restent applicables au niveau de Rectangle.

En pratique, il arrive qu'on souhaite exposer des entités permettant d'accéder directement aux attributs d'un objet. On n'a qu'à penser aux itérateurs dans un conteneur comme std::vector. Certains objets ont une vocation de sécurité, d'autres ont plus une vocation utilitaires. En pratique, il y a de la place pour les deux.

#include "Rectangle.h"
class Bouton {
   // ...
   Rectangle dimension_;
   // ...
public:
   // ...
   const Rectangle& dimension() const {
      return dimension_;
   }
   // ...
};

Imaginez la situation suivante :

#include <string>
class Y {
   const std::string &nom_; // ne faites pas ça; ce n'est qu'un exemple!
public:
   Y(const std::string &nom) : nom_{nom} {
   }
   std::string nom() const {
      return nom_;
   }
};
class X {
   std::string nom_;
public:
   X(const std::string &nom) : nom_{nom} {
   }
   const std::string &nom() const { // est-ce sage?
      return nom_;
   }
   void renommer(const std::string &nom) {
      nom_ = nom;
   }
};
#include <iostream>
usinf namespace std;
void f(const X &x) {
   X x{"J'aime mon prof");
   Y y{x.nom()};
   cout << "Le nom de y est const --> " << y.nom() << endl;
   x.renommer("Surprise");
   cout << "Le nom de y est ... Oups! " << y.nom() << endl;
}

Ici, y possède une référence qualifée const et, concrètement, ne fait rien pour briser cette qualification; de son côté, x retourne une référence qualifiée const par sa méthode nom(), elle-même qualifiée const. Tout est donc correct localement. Le problème est plus global : l'invocation de x.renommer() modifie la string dans x, à laquelle réfère y. La « constante » logée dans y est donc modifiée, à son insu!

Si X::nom() retournait une string plutôt qu'une const string&, ce problème serait évacué. Conséquemment, dans le respect de la sémantique attendue d'une constante, les copies sont un outil inestimable.

La capacité de manipuler des objets constants est donc fondamentale. Un objet doit être en mesure d'utiliser des objets à la fois pour représenter ses états et pour communiquer avec les autres objets. Pour qu'un objet puisse assurer le respect du principe d'encapsulation, il lui faut être certain que ses clients n'obtiendront pas à son insu un accès privilégié à ses entrailles de manière telle qu'il deviendrait possible de le saboter.

Lorsque les objets sont manipulés par sémantique de valeur, la constance prend une moins grande place du fait que la plupart des opérations susceptibles de compromettre un objet ou l'autre tendent à générer des copies. En retour, les sémantiques indirectes compromettent souvent, facilement et sournoisement l'encapsulation et, par le fait même, la solidité des programmes.

Immuabilité (constantes sur une base classe)

Un exemple de code Java couvrant les diverses opérations proposées pour la classe Rectangle serait :

class TailleInvalide extends Exception {
   public TailleInvalide () {
      super ("Taille invalide");
   }
}
public class Rectangle {
   private static final short
      LARGEUR_MIN =  1, HAUTEUR_MIN =  1,
      LARGEUR_MAX = 80, HAUTEUR_MAX = 24,
      LARGEUR_DÉFAUT = 5, HAUTEUR_DÉFAUT = 3;
   private static boolean estHauteurValide(short hauteur) {
      return HAUTEUR_MIN <= hauteur && hauteur <= HAUTEUR_MAX;
   }
   private static boolean estLargeurValide(short Largeur) {
      return LARGEUR_MIN <= largeur && largeur <= LARGEUR_MAX;
   }
   public Rectangle() {
      setLargeurBrut(LARGEUR_DÉFAUT);
      setHauteurBrut(HAUTEUR_DÉFAUT);
   }
   public Rectangle(short hauteur, short largeur) throws TailleInvalide {
      // versions publiques et blindées
      setHauteur(hauteur);
      setLargeur(largeur);
   }
   protected Rectangle(Rectangle r) {
      setLargeurBrut(r.largeur());
      setHauteurBrut(r.hauteur());
   }
   // accesseurs publics -- interface de consultation
   // accesseurs de premier ordre
   public short getLargeur() {
      return largeur_;
   }
   public short getHauteur() {
      return hauteur_;
   }
   // accesseurs de second ordre
   public short getPérimètre() {
      return 2 * (largeur() + hauteur());
   }
   public short getSurface() {
      return largeur() * hauteur();
   }
   // mutateurs publics -- interface de modification contrôlée
   // versions publiques et blindées
   public void setHauteur(short hauteur) throws TailleInvalide {
      if (!estHauteurValide(hauteur)) {
         throw new TailleInvalide();
      }
      setHauteurBrut(hauteur);
   }
   public void setLargeur(short largeur) throws TailleInvalide {
      if (!estLargeurValide(largeur)) {
         throw new TailleInvalide();
      }
      setLargeurBrut(largeur);
   }
   // mutateurs privés -- interface de modification primitive
   // versions privées et rapides
   private void setHauteurBrut(short hauteur) {
      hauteur_ = hauteur;
   }
   private void setLargeurBrut(short largeur) {
      largeur_ = largeur;
   }
   // méthode de projection à la console
   public void dessiner() {
      for (short i = 0; i < getHauteur(); ++i) {
         for (short j = 0; j < getLargeur(); ++j) {
            System.out.print("*");
         }
         System.out.println();
      }
   }
   public Rectangle cloner() {
      return new Rectangle(this);
   }
   //
   // ...plusieurs autres méthodes (laissez-vous aller)...
   //
}

Le code C# et le code VB.NET sont du même niveau de complexité, avec les mêmes qualités, les mêmes défauts et les mêmes stratégies de solution. Je m'en tiendrai ici au cas Java par souci d'économie et de simplicité.

Remarquons tout d'abord que la version Java est fonctionnellement équivalente à la version C++. Cependant, en comparaison avec la version C++, les clauses de constance sont disparues. La raison en est simple : Java et les langages .NET ne supportent pas le concept de constante au niveau des objets ou des méthodes.

En apparence, ceci ne semble pas poser de problème. En effet, plusieurs programmes .NET et plusieurs programmes Java existent sur la planète et tout semble fonctionner comme sur des roulettes. En pratique, malgré la réputation de langage dangereux faite à C++ et la réputation de langage sécuritaire faite à Java et aux langages .NET, la situation concrète est que l'absence d'objets constants rend l'immense majorité des programmes Java et .NET vulnérables. Pas au même titre, bien sûr (en C++ après tout, on peut prendre un pointeur, changer son sens avec un reinterpret_cast et faire à peu près ce qu'on veut, à l'endroit de notre choix), mais au sens où puisque tous les objets sont manipulés indirectement, il asrrive très, très souvent que deux références mènent au même objet; dans un tel cas, modifier l'objet par l'une des références modifie aussi l'objet pour l'autre référence (c'est, tout simplement, le même objet). C'est d'ailleurs ce qu'on appelle du aliasing.

Attention : Java et les langages .NET n'empêchent pas la rédaction de programmes sécuritaires mais leurs modèles respectifs en compliquent fortement la rédaction. La plupart des programmeurs génèrent du code à risque sans même s'en apercevoir.

public class Bouton {
   // ...
   private Rectangle dimension_;
   // ...
   public void setDimension(Rectangle r) {
      // validations, p. ex. : if (r != null) ...
      dimension_ = r;
   }
   public Rectangle getDimension() {
      return dimension_;
   }
   // ...
}
class Test {
   public static void main(String [] args) {
      Bouton b = new Bouton();
      // ...
      Rectangle r = new Rectangle();
      // ...
      b.setDimension(r);
      // ...
      r = b.getDimension();
   }
}

Remarquez que le code client (classe Test) est aussi vulnérable que l'objet en tant que tel: si un Bouton et son client ont tous deux une référence sur un même Rectangle, le Bouton peut tout autant modifier le Rectangle à l'insu de son client que le client peut modifier le Rectangle à l'insu du Bouton. En l'absence de constantes, les deux se mettent mutuellement à risque.

Deux options existent pour permettre à un objet à la fois d'offrir des services et d'assurer sa propre intégrité : adopter des stratégies de programmation défensive et avoir recours à des classes immuables.

Stratégies de programmation défensive

La programmation défensive est une manière par laquelle un objet, manipulé indirectement comme le sont toutes les classes Java, toutes les classes C#, et les objets manipulés par des indirections (pointeurs ou références) en C++, peut réduire les risques de coruption non-sollicitée. Évidemment, la meilleure solution à ce problème est d'avoir un accès direct aux objets, mais cela n'est pas possible en Java ou en C# alors il faut parfois se faire violence (en toute honnêteté, la plupart des programmeuses et des programmeurs ne se rendront pas jusque là, et accepteront que leur programme soit brisé, ou – mieux – utiliseront des classes immuables).

public class Bouton {
   // ...
   private Rectangle dimension_;
   // ...
   public void setDimension(Rectangle r) {
      // validations, ex.: if (r != null) ...
      dimension_ = r.cloner();
   }
   public Rectangle getDimension() {
      return dimension_.cloner();
   }
   // ...
}
class Test {
   public static void main(String [] args) {
      Bouton b = new Bouton();
      // ...
      Rectangle r = new Rectangle();
      // ...
      b.setDimension(r.cloner());
      // ...
      r = b.getDimension().cloner();
   }
}

Vous remarquerez tout de suite que la programmation défensive est très coûteuse en ressources. Cette stratégie implique d'insérer beaucoup de code manuel de duplication (par clonage puisque les objets retournés par les méthodes ou utilisés comme paramètres à des méthodes sont habituellement polymorphiques) même si, dans bien des cas, le client et son objet réaliseront la duplication deux fois plutôt qu'une, chacun d'entre eux devant se protéger et ne pouvant présumer de la bonne foi de l'autre.

Le résultat direct est que le code sera beaucoup plus lent et que la collecte automatique d'ordures sera utilisée beaucoup plus souvent en pratique, le nombre d'objets temporaires (et souvent inutiles) augmentant de manière significative. Ce coût est nécessaire en l'absence d'un mécanisme capable d'assurer la constance des objets dans ces langages.

Entendons-nous: le mot nécessaire ici signifie nécessaire en général. Pour des systèmes qui ne sont utilisés qu'à l'intérieur d'une entreprise et qui ne sont pas susceptibles d'être exposés au monde extérieur, la compromission de l'encapsulation demeure mais les chances qu'un tiers exploite (volontairement ou accidentellement) cette faille sont plus faibles. Les bris d'encapsulation sont surtout dangereux lorsque le code est utilisé dans plusieurs milieux ou par plusieurs types de clientèles – pour une API ou pour du code de bibliothèque, les fautes de ce genre sont impardonnables.

Classes et interfaces immuables

L'alternative à privilégier dans les langages qui ne supportent pas les constantes et qui n'offrent que des sémantiques indirectes est l'approche par classes et interfaces immuables. Pour être stricts, nous pourrions indiquer qu'une classe peut être immuable et qu'une interface peut suggérer l'immutabilité puisqu'une interface ne contient pas de code à proprement dit.

Une entité immuable est une classe ou une interface n'offrant aucun service par lequel il est possible de modifier ses états. Plusieurs classes standard des infrastructures Java et .NET sont immuables, la plus célèbre étant la classe String (ou string en C#).

Puisqu'une entité immuable ne peut être modifiée une fois qu'elle a été construite, la programmation à l'aide d'objets immuables sollicite à fond les mécanismes d'allocation dynamique de mémoire et de collecte automatique d'ordures. Pour cette raison, la plupart des classes immuables ont une contrepartie qui n'est pas immuable et permet la modification d'états sans imposer un recours démesuré à ces mécanismes.

En Java, la classe String a une contrepartie modifiable nommée StringBuffer. Sous .NET, la classe System.String (qui a un alias C# nommé string) a une contrepartie modifiable nommée System.Text.StringBuilder. Dans les deux cas, la raison est simple: les manipulations sur des chaînes coûtent tellement cher en création et en récupération d'objets temporaires qu'elles constituent des goulots d'étranglement dans un nombre important de programmes et il est essentiel d'offrir une contrepartie efficace aux classes plus typiques mais inefficaces en pratique.

Si nous décidons d'appliquer une stratégie d'immutabilité à la classe Rectangle, nous avons deux grandes familles d'options.

interface RectangleConsultation {
   short gerLargeur();
   short getHauteur();
   short dessiner();
}
class Rectangle
   implements RectangleConsultation {
   // ...
}
class Bouton {
   // ...
   Rectangle dimension_;
   // ...
   public RectangleConsultation dimension() {
      return dimension_;
   }
}

final class RectangleModifiable {
   //
   // ... ce qui était Rectangle plus haut ...
   //
   public RectangleModifiable(Rectangle r) {
      // ...
   }
   // ...
}
final class Rectangle {
   // ... ce qui était Rectangle plus haut
   // mais sans méthodes pour le modifier ...
   // ...
   public Rectangle(RectangleModifiable r) {
      // ...
   }
   // ...
}
class Bouton {
   // ...
   private RectangleModifiable dimension_;
   // ...
   public Rectangle getDimension() {
      return new Rectangle(dimension_);
   }
}

En général, dans les langages .NET comme avec Java et d'autres langages similaires du point de vue du système de types, les classes et les interfaces immuables sont l'idiome à privilégier pour prévenir les bris d'encapsulation.

Cet idiome n'est malheureusement pas une panacée. Il ne permet pas d'introduire de constance une instance à la fois ou d'offrir des garanties de constance méthode par méthode. Il exige aussi un effort de programmation supplémentaire considérable en imposant la duplication d'une partie importante du code.

Constance et pragmatisme – le concept de mutabilité

Revenons aux constantes d'un point de vue plus pragmatique. Prenons la classe Rectangle dans sa déclinaison C++ et imaginons qu'on souhaite évaluer le rapport entre la fréquence des appels aux accesseurs de second ordre (surface() et perimetre()) et la fréquence d'appels aux mutateurs primitifs (en insérant des mutateurs privés SetLargeurBrut() et SetHauteurBrut()).

L'idée est que nous souhaitons déterminer s'il est avantageux (ou non) de conserver la surface et le périmètre d'un Rectangle dans des attributs. Une telle stratégie sera en effet avantageuse (côté vitesse) dans le cas où la hauteur et la largeur changent peu souvent ou dans le cas où on demande souvent à un Rectangle sa surface et son périmètre, du fait que les calculs seront faits occasionnellement et leur résultat sera utilisé fréquemment. Elle sera par contre désavantageuse si la largeur et la hauteur changent souvent ou dans le cas où on demande rarement à un Rectangle sa surface et son périmètre, ce qui entraînerait des calculs fréquents pour des consultations occasionnelles.

Le problème est alors que, pour être à la fois propre et efficace, nous voudrons qu'un Rectangle tienne à jour ses propres statistiques d'utilisation. Cependant, si un attribut compte les appels aux accesseurs de second ordre, nous voudrons qu'il soit incrémenté lors de chaque appel, mais ceci nous empêchera de spécifier surface() et perimetre() constants!

//
// Rectangle.h
//
#include <iosfwd>
class Rectangle {
public:
   // type interne public
   using size_type = short;
private:
   // une implémentation possible (parmi plusieurs)
   size_type hauteur_,
            largeur_;
   enum : size_type {
      LARGEUR_MIN =  1, HAUTEUR_MIN =  1,
      LARGEUR_MAX = 80, HAUTEUR_MAX = 24,
      LARGEUR_DEFAUT = 5, HAUTEUR_DEFAUT = 3,
   };
   static bool est_hauteur_valide(const size_type hauteur) {
      return HAUTEUR_MIN <= hauteur && hauteur <= HAUTEUR_MAX;
   }
   static bool est_largeur_valide (const size_type largeur) {
      return LARGEUR_MIN <= largeur && largeur <= LARGEUR_MAX;
   }
   int nbconsultations_ = 0,
       nbmodifications_ = 0;
public:
   //
   // Sainte-Trinité omise car implicitement correcte
   //
   Rectangle() : largeur_{LARGEUR_DEFAUT}, hauteur_{HAUTEUR_DEFAUT} {
   }
   Rectangle(size_type hauteur, size_type largeur)  {
      // versions publiques et blindées
      SetHauteur(hauteur);
      SetLargeur(largeur);
   }
   // accesseurs publics -- interface de consultation
   // accesseurs de premier ordre
   size_type largeur () const noexcept {
      return largeur_;
   }
   size_type hauteur () const noexcept {
      return hauteur_;
   }
   // accesseurs de second ordre
   size_type perimetre() const noexcept {
      ++nbconsultations_; // illégal si la méthode est const!
      return 2 * (largeur() + hauteur());
   }
   size_type surface() const noexcept {
      ++nbconsultations_; // illégal si la méthode est const!
      return largeur() * hauteur();
   }
   // mutateurs publics -- interface de modification contrôlée
   // versions publiques et blindées
   void SetHauteur(size_type hauteur) {
      if (!est_hauteur_valide(hauteur)) throw TailleInvalide{};
      SetHauteurBrut(hauteur);
   }
   void SetLargeur(size_type largeur) {
      if (!est_largeur_valide(largeur)) throw TailleInvalide{};
      SetLargeurBrut(largeur);
   }
private:
   // mutateurs privés -- interface de modification primitive
   // versions privées et rapides
   void SetHauteurBrut(size_type hauteur) noexcept {
      ++nbmodifications_;
      hauteur_ = hauteur;
   }
   void SetLargeurBrut(size_type largeur) noexcept {
      ++nbmodifications_;
      largeur_ = largeur;
   }
public:
   // méthode de projection à la console
   void dessiner() const;
   //
   // ...plusieurs autres méthodes (laissez-vous aller)...
   //
};

// projection sur un flux arbitraire
std::ostream& operator<<(std::ostream&, const Rectangle&);

//
// Rectangle.cpp
//
#include "Rectangle.h"
#include <iostream>
using namespace std;

void Rectangle::dessiner() const {
   cout << *this;
}

ostream& operator<<(ostream &os, const Rectangle &r) {
   using size_type = Rectangle::size_type;
   for (size_type i = 0; i < r.hauteur(); ++i) {
      for (size_type j = 0; j < r.largeur(); ++j)
         os << '*';
      os << endl;
   }
   return os;
}

Remarquez toutefois que les attributs à vocation statistique ne sont pas vraiment des attributs de Rectangle. Ce sont des données d'appoint, utiles à des fins techniques sans être conceptuellement reliées à l'intégrité d'un Rectangle. Que nous souhaitions les utiliser pour compter des appels ne change rien au fait que les dimensions du Rectangle demeurent intactes.

Dans un tel cas, nous voulons (sans abuser!) pouvoir indiquer au compilateur que certains attributs n'ont pas à être soumis aux règles de constance. Un attribut qui sera soustrait à la contrainte de constance est un attribut mutable. Identifier une donnée comme mutable permet d'écrire du code à la fois robuste (respect plein et entier de l'encapsulation[2]) et pragmatique (flexibilité à l'interne quant à l'application des règles et contraintes de constance).

Les cas types d'attributs mutables sont des attributs à vocation statistique et des attributs à vocation d'optimisation (pensez à une antémémoire qui éviterait certains accès à un média plus lent).

Le code ajusté suit.

//
// Rectangle.h
//
#include <iosfwd>
class Rectangle {
public:
   // type interne public
   using size_type = short;
private:
   // une implémentation possible (parmi plusieurs)
   size_type hauteur_,
            largeur_;
   enum : size_type {
      LARGEUR_MIN =  1, HAUTEUR_MIN =  1,
      LARGEUR_MAX = 80, HAUTEUR_MAX = 24,
      LARGEUR_DEFAUT = 5, HAUTEUR_DEFAUT = 3,
   };
   static bool est_hauteur_valide(const size_type hauteur) {
      return HAUTEUR_MIN <= hauteur && hauteur <= HAUTEUR_MAX;
   }
   static bool est_largeur_valide (const size_type largeur) {
      return LARGEUR_MIN <= largeur && largeur <= LARGEUR_MAX;
   }
   mutable int nbconsultations_ = 0,
               nbmodifications_ = 0;
public:
   //
   // Sainte-Trinité omise car implicitement correcte
   //
   Rectangle() : largeur_{LARGEUR_DEFAUT}, hauteur_{HAUTEUR_DEFAUT} {
   }
   Rectangle(size_type hauteur, size_type largeur) {
      // versions publiques et blindées
      SetHauteur(hauteur);
      SetLargeur(largeur);
   }
   // accesseurs publics -- interface de consultation
   // accesseurs de premier ordre
   size_type largeur () const noexcept {
      return largeur_;
   }
   size_type hauteur () const noexcept {
      return hauteur_;
   }
   // accesseurs de second ordre
   size_type perimetre() const noexcept {
      ++nbconsultations_; // illégal si la méthode est const!
      return 2 * (largeur() + hauteur());
   }
   size_type surface() const noexcept {
      ++nbconsultations_; // illégal si la méthode est const!
      return largeur() * hauteur();
   }
   // mutateurs publics -- interface de modification contrôlée
   // versions publiques et blindées
   void SetHauteur(size_type hauteur) {
      if (!est_hauteur_valide(hauteur)) throw TailleInvalide{};
      SetHauteurBrut(hauteur);
   }
   void SetLargeur(size_type largeur) {
      if (!est_largeur_valide(largeur)) throw TailleInvalide{};
      SetLargeurBrut(largeur);
   }
private:
   // mutateurs privés -- interface de modification primitive
   // versions privées et rapides
   void SetHauteurBrut(size_type hauteur) noexcept {
      ++nbmodifications_;
      hauteur_ = hauteur;
   }
   void SetLargeurBrut(size_type largeur) noexcept {
      ++nbmodifications_;
      largeur_ = largeur;
   }
public:
   // méthode de projection à la console
   void dessiner() const;
   //
   // ...plusieurs autres méthodes (laissez-vous aller)...
   //
};

// projection sur un flux arbitraire
std::ostream & operator << (std::ostream &, const Rectangle &);

//
// Rectangle.cpp
//
#include "Rectangle.h"
#include <iostream>
using namespace std;

void Rectangle::dessiner() const {
   cout << *this;
}

ostream& operator<<(ostream &os, const Rectangle &r) {
   using size_type = Rectangle::size_type;
   for (size_type i = 0; i < r.hauteur(); ++i) {
      for (size_type j = 0; j < r.largeur(); ++j)
         os << '*';
      os << endl;
   }
   return os;
}

Un peu plus loin – constexpr

Depuis C++ 11, le concept de constance va plus loin encore et il devient possible d'exprimer au compilateur qu'une fonction doit être évaluée à la compilation, dans la mesure où ses paramètres sont connus à ce stade. Ce mécanisme couvre même les constructeurs, ce qui permet d'avoir des objets construits à même le code machine généré, avant le début de l'exécution d'un programme, et de les placer en mémoire Read-Only si cela s'avère à propos.

Ce mécanisme repose sur le mot clé constexpr, qui ne signifie pas « ne changera pas d'état » mais bien « est résolu dès la compilation ». Un exemple un peu banal suit; observez les méthodes qualifiées constexpr, car elles partagent quelques caractéristiques (pour être légales avec C++ 11) :

• Elles peuvent appeler d'autres fonctions si celles-ci sont aussi qualifiées constexpr
• Elles se limitent à une seule expression. Cette expression pourrait toutefois être récursive, et peut solliciter l'opérateur ternaire (le ?:)
• Il est possible qu'elles lèvent une exception, mais dans ce cas elles seront évaluées à l'exécution

//
// Rectangle.h
//
#include <iosfwd>
class HauteurIncorrecte {};
class LargeurIncorrecte {};
class Rectangle {
public:
   // type interne public
   using size_type = short;
private:
   // une implémentation possible (parmi plusieurs)
   size_type hauteur_,
            largeur_;
   enum : size_type {
      LARGEUR_MIN =  1, HAUTEUR_MIN =  1,
      LARGEUR_MAX = 80, HAUTEUR_MAX = 24,
      LARGEUR_DEFAUT = 5, HAUTEUR_DEFAUT = 3,
   };
   static constexpr bool est_hauteur_valide(size_type hauteur) {
      return HAUTEUR_MIN <= hauteur && hauteur <= HAUTEUR_MAX;
   }
   static constexpr bool est_largeur_valide(size_type largeur) {
      return LARGEUR_MIN <= largeur && largeur <= LARGEUR_MAX;
   }
   static constexpr size_type valider_hauteur(size_type valeur) {
      return !est_hauteur_valide(valeur)? throw HauteurIncorrecte{} : valeur;
   }
   static constexpr size_type valider_largeur(size_type valeur) {
      return !est_largeur_valide(valeur)? throw LargeurIncorrecte{} : valeur;
   }
public:
   constexpr Rectangle() : largeur_{ LARGEUR_DEFAUT }, hauteur_{ HAUTEUR_DEFAUT } {
   }
   constexpr Rectangle(size_type hauteur, size_type largeur)
      : hauteur_{ valider_hauteur(hauteur) }, largeur_{ valider_largeur(largeur) }
   {
   }
   //
   // Sainte-Trinité : implicite
   //
   // accesseurs publics -- interface de consultation
   // accesseurs de premier ordre
   constexpr size_type largeur() const noexcept {
      return largeur_;
   }
   constexpr size_type hauteur() const noexcept {
      return hauteur_;
   }
   // accesseurs de second ordre
   constexpr size_type perimetre() const noexcept {
      return 2 * (largeur() + hauteur());
   }
   constexpr size_type surface () const noexcept {
      return largeur() * hauteur();
   }
   // méthode de projection à la console
   void dessiner() const;
   //
   // ...plusieurs autres méthodes (laissez-vous aller)...
   //
};
// projection sur un flux arbitraire
std::ostream& operator<<(std::ostream&, const Rectangle&);

//
// Rectangle.cpp
//
#include "Rectangle.h"
#include <iostream>
using namespace std;
void Rectangle::dessiner() const {
   cout << *this;
}
ostream& operator<<(ostream &os, const Rectangle &r) {
   using size_type = Rectangle::size_type;
   for (size_type i = 0; i < r.hauteur(); ++i) {
      for (size_type j = 0; j < r.largeur(); ++j)
         os << '*';
      os << endl;
   }
   return os;
}

Un programme de test simple mais correct pour cette classe serait :

int main() {
   constexpr Rectangle rect{3,7};
   cout << rect << endl;
}

Ici, rect sera évaluée et construit dès la compilation, mais son affichage sera réalisé à l'exécution.

Lectures complémentaires

Plusieurs ont écrit sur le sujet de l'immuabilité et de la constance. Quelques propositions de lectures suivent.

À propos du mot const :

• Le pourquoi et le comment de const en C++, texte d'Andrew Hardwick en 2001 : http://duramecho.com/ComputerInformation/WhyHowCppConst.html
• Dans ce texte de 2014, Fredrik Haikarainen explique comment lire les déclarations incluant la qualification const : http://www.fredrikhaikarainen.se/understanding-const-declarations/

À propos de l'immuabilité :

• Avantages pratiques de l'immuabilité, texte d'Andrew Koenig en 2013 : http://www.drdobbs.com/cpp/practical-advantages-of-immutable-values/240163690
• En quoi l'immuabilité en Haskell permet une automatisation de la mémoisation, par Andrew Koenig en 2013 : http://www.drdobbs.com/cpp/when-is-an-optimization-more-than-just-a/240163939
• Texte de 2014 sur les vertus de l'immuabilité : http://www.codergears.com/Blog/?p=486

Autres :

• Réflexion sur l'utilité et sur le rôle des constantes dans plusieurs langages de programmation (mais particulièrement en VB.NET), par Peter Vogel en 2014 : http://visualstudiomagazine.com/articles/2014/03/01/a-constant-issue.aspx

[0] En premier lieu, j'avais utilisé effets de bord, mais effets secondaires est plus adéquat. Un éminent collègue m'a suggéré effets secondaires et effets indésirables en privilégiant effets indésirables; cependant, la plupart des effets secondaires découlant de la vie d'un objet me semblent désirés (après tout, dans la plupart des cas, un objet qui consomme des ressources le fait volontairement) alors j'ai privilégié effets secondaires, plus près de ma pensée ici.

[1] Prenez consultation au sens de qui ne modifient pas l'objet.

[2] Cette affirmation a fait réagir certains de mes estimés collègues et amis, et je comprends leur réaction. L'idée que je veux mettre de l'avant ici est que l'objet veut protéger ses états (on me souligne que états fondamentaux aurait peut-être été moins sujet à polémique ici), mais que certains attributs d'instance, bien qu'ils soient utiles à l'objet, ne sont pas des états au sens où on l'entend. Dans le cas du Rectangle, le décompte statistique des invocations de chaque catégorie de service est un état temporaire et qui n'est pas tant un état de Rectangle qu'un état utilitaire (et peut-être transitoire) pour la mise au point du programme. Conceptuellement, les véritables états d'un objet devraient rester constants lors de l'invocation d'une méthode constante (il y a peut-être des cas d'exception, mais ceux-ci devraient être rares et pointus); on s'attend à ce que les attributs mutables soient auxiliaires et disjoints de la nature de l'objet représenté. C'est ce qui explique mon choix de parler de respect plein et entier de l'encapsulation ici: au sens où je l'entends dans ce passage, un attribut comme nbmodifications_ n'est pas un état réel de Rectangle. Cela dit, je comprends le caractère polémique de l'affirmation et je ne prétends pas avoir trouvé la meilleure formule pour exprimer l'idée que je cherche à mettre de l'avant dans ce passage, alors les suggestions sont les bienvenues.