Programmation par contrat, application en C++

Les préconditions, ce sont les conditions nécessaires et suffisantes à la bonne exécution de la fonction. Par exemple :

double racine_carree(x)

a une précondition assez évidente, qui est x >= 0.

En programmation classique, cette précondition n'est jamais exprimée, elle est implicite. Aussi, le programmeur doit deviner, à partir de ce que fait la fonction, quelles sont ses préconditions. L'expérience montre que le programmeur a souvent tendance à croire que la fonction qu'il appelle, en fait plus que ce qu'elle ne fait réellement. Aussi, en programmation par contrat, sont incluses, dès la conception, les conditions nécessaires et suffisantes à l'appel de la fonction. À charge de l'appelant de s'assurer qu'il les respecte.

La fonction sera donc déclarée de la sorte (en pseudocode) :

double racine_carree(x) require x >= 0;

La différence peut paraître mineure, mais elle est fondamentale. En exprimant ces préconditions, on garantit à l'appelant que, s'il les respecte, on aura un comportement défini.

Qu'est-ce qu'une bonne précondition, comment dois-je définir mes préconditions ?

Une bonne précondition répond aux critères suivants :

• elle est vérifiable par l'appelant : nous verrons pourquoi plus loin ;
• elle porte généralement sur les paramètres de la fonction ;
• je n'ai pas défini de comportement, si elle n'est pas respectée ;
• dès que l'on respecte mes préconditions, j'ai un comportement défini.

Une fonction peut bien entendu avoir plusieurs préconditions. Comme une précondition est une expression booléenne, ces préconditions peuvent se combiner au moyen des opérateurs logiques OU et ET. Sans autre précision, le défaut est l'opérateur ET. La fonction strlen, par exemple, pourrait s'exprimer comme ceci :

int strlen(char * s) 
  require s != NULL
  require « s terminée par un \0 »

La postcondition, c'est une propriété qui est vérifiée lorsque la fonction est terminée. Là encore, en programmation classique, elle n'est jamais exprimée. En programmation par contrat, elle sera exprimée dans la déclaration de la fonction, par exemple :

int carre(x) ensure return >= 0

Ce que cette postcondition dit, c'est que la valeur de retour de « carre » est positive. Ce qui était implicite, que le développeur devait deviner, est désormais exprimé : garanti noir sur blanc. Cela fait désormais partie du contrat.

Comment définir une bonne postcondition ?

Les postconditions ont un gros problème par rapport aux préconditions. On ne sait pas exactement comment s'arrêter, car l'ensemble des choses que l'on peut garantir est virtuellement infini. Ainsi, on peut très bien écrire :

int carre(x)
  ensure return >=0
  ensure "la réponse à la question sur la vie, l'univers et le reste est 42"

Aussi, pour qu'une postcondition soit utile, il faut qu'elle réponde au moins à l'une des caractéristiques suivantes :

• elle porte sur la valeur de retour de la fonction ;
• elle porte sur l'un des paramètres de la fonction (passé par référence, par exemple) ;
• elle apporte une information utile.

Le dernier point est le plus sujet à discussion. En reprenant nos deux exemples et seulement en lisant les contrats, on sait que l'on a le droit d'écrire :

double x = racine_carree(carre(-3.4));

En effet, la postcondition de « carre » vérifie la précondition de « racine_carree », aussi, grâce à mes contrats, j'ai la garantie que mon code va fonctionner. On peut donc dire que ma postcondition m'est utile. De la même manière, la méthode push_back de la classe std::vector se déclare de la sorte :

std::vector::push_back(T) ensure size() == pre.size() + 1

Ou, autrement dit, on garantit qu'après push_back, la taille de mon vecteur a augmenté de 1, et donc, que l'on peut appeler pop_back() sans vérifier que la taille est supérieure à zéro.

II-B-1. Postconditions et exceptions▲

Maintenant que nous savons définir un contrat, reste à déterminer à qui échoit quoi. De manière assez logique, le respect des postconditions ne peut être que le fait de l'appelé, l'appelant n'ayant pas la main dessus.

De manière moins évidente, c'est l'appelant qui est responsable des préconditions. En effet, les préconditions sont les conditions nécessaires et suffisantes pour appeler la fonction. De fait, elles doivent être respectées avant même de rentrer dans le corps de l'appelé. C'est donc à l'appelant qu'elles échoient.

Le contrat est donc bien un engagement bipartite, entre l'appelant et l'appelé. L'appelant s'engage sur les préconditions et l'appelé s'engage sur les postconditions. Si les préconditions ne sont pas respectées, il faut corriger le code de l'appelant. Si les postconditions ne sont pas respectées, il faut corriger le code de l'appelé.

Rapidement se pose la question de la rupture du contrat. Que se passe-t-il si l'une des deux parties ne respecte pas ses engagements ? À cela, la programmation par contrat n'impose rien. Dès lors que les deux parties n'ont pas fait leur part du contrat, le programme est faux et il est inutile d'essayer de se « rattraper aux branches » (sauf, bien sûr, si des vies humaines sont en jeu). Il faut avant tout corriger le programme.

Ceci s'oppose complètement à la programmation défensive, qui elle, vise à rejeter tout paramètre invalide et à renvoyer l'appelant dans les cordes au moyen d'une exception (dont, souvent, il ne saura pas quoi faire).

Maintenant que vous savez qu'un contrat non vérifié est un comportement indéfini et qu'un programme correct respecte toujours ses contrats, se pose la question de savoir s'il faut tester la validité le contrat.

La réponse n'est pas si évidente qu'elle en a l'air. Tester le contrat est utile, car cela permet de changer un comportement indéfini en un comportement défini (par exemple, lever une exception), qui permettra de diagnostiquer rapidement l'erreur. Mais tester le contrat a un coût, qu'il n'est pas nécessaire de payer si le programme est correct.

De fait, ce qui est souvent fait est de vérifier le respect du contrat lors de la phase de débogage et de ne plus le faire lors de la phase de release. Ce qu'il est indispensable de vérifier, c'est que le comportement du programme est le même, que cette vérification soit activée ou pas. On parle de neutralité du contrat, car celui-ci est totalement neutre du point de vue de l'exécution du programme.

L'objet ayant un état, on peut définir des propriétés sur cet état, qui sont toujours vérifiées. Une sorte de pré/postcondition universelle, respectée par l'ensemble des routines publiques (y compris protégées) de l'objet. Ces propriétés sont appelées invariants de classe.

Les invariants sont valides en entrée et en sortie de chaque routine, toutefois, il est tout à fait possible de rompre ces invariants, le temps d'un traitement. Ce n'est pas un problème du moment qu'une fois sorti de la routine, l'invariant est de nouveau respecté.

Pour prendre l'exemple de la classe std::vector, un invariant de cette classe est que la taille du vecteur est toujours supérieure ou égale à zéro.

L'invariant n'est pas nécessairement une propriété visible depuis l'extérieur, en effet, c'est une garantie, le client n'a pas d'influence dessus. Toutefois, comme pour les postconditions, l'invariant doit donner une information utile au client.

III-A-1. Invariants et exceptions▲

Avant d'aller plus loin, il faut définir de quel héritage on parle. La programmation par contrat s'intéresse avant tout à l'héritage polymorphique. Pour faire un programme correct et réutilisable, il est essentiel d'avoir un certain nombre de garanties. Dans le cas de l'héritage polymorphique, la garantie que l'on veut est que si on crée une classe B qui dérive de A, alors, tout le code déjà écrit, qui utilise des A, est valide pour un B. Cette propriété est aussi connue sous le nom de Principe de Substitution de Liskov (LSP en anglais).

Afin d'avoir cette garantie, il existe un outil formidable qui est le contrat. Si B respecte le même contrat que A, alors, B est substituable à A. Mais on perd beaucoup en flexibilité. Heureusement, c'est un peu plus souple :

• les préconditions peuvent en effet être étendues. Le minimum est que la routine de B fonctionne pour l'ensemble des valeurs admises par celle de A, mais rien ne l'empêche de faire plus ;
• les postconditions peuvent être renforcées. Là aussi, le minimum est de garantir la même chose que ce que faisait A, mais il est toujours possible de garantir plus ;
• les invariants doivent être respectés, mais il est possible d'en définir de nouveaux, à condition de s'assurer que les routines définies dans A, susceptibles d'être appelées, ne les violent pas. En général, on définira de nouveaux invariants sur des membres n'existant pas dans A.

C++, comme la plupart des langages de programmation, n'inclut aucun mécanisme pour définir et gérer des contrats. Cela dit, quand on y regarde de plus près, il existe déjà des « contrats » en C++.

V-A-1. Le typage, vu du point de vue contrat▲

int f(int a, double b);

V-A-2. Le cas de const▲

int A::f(std::string const & chaine) const;

Il est possible, à l'aide du préprocesseur, de définir des macros qui simplifieront l'écriture des contrats. L'idée étant que le code doit être le plus lisible possible, toute la complexité sera laissée à l'écriture de la macro. Nous allons donc pour l'instant nous contenter d'écrire :

double sqrt(double d)
{
        REQUIRE(d >= 0, "d positif");
        …
        ENSURE(retour >= 0,"Valeur de retour positive")
}
 
class MaClasse
{
 public:
        int size();
        BEGIN_INVARIANT_BLOCK(MaClasse) 
        INVARIANT(size() >= 0, "La taille est positive");
        END_INVARIANT_BLOCK
}

Il faut remarquer deux choses. Nous avons exprimé la condition que doit respecter l'appelant, et ce à la fois sous la forme du test qui sera effectué par le programme et sous une forme textuelle décrivant la précondition. Il est important de bien assimiler ceci pour comprendre les messages d'erreurs qui seront remontés en cas de violation de contrat. Le texte inscrit sera utilisé pour décrire l'exception.

Il peut paraître étrange de passer « MaClasse » comme paramètre à BEGIN_INVARIANT_BLOCK, alors que l'on est déjà dans le corps de la classe. D'un point de vue C++, c'est strictement inutile. En revanche, cela se révèle nécessaire pour générer la documentation avec Doxygen.

La gestion des invariants est malheureusement un peu plus problématique. Certes, on a bien défini nos invariants de classe, mais ils ne seront pas vérifiés. On va devoir rajouter en entrée et en sortie de chaque fonction membre, un appel à une macro CHECK_INVARIANTS.

double MaClasse::f(double d)
{
        CHECK_INVARIANTS();
        REQUIRE(d >= 0, "d positif");
        …
        ENSURE(retour >= 0,"Valeur de retour positive")
        CHECK_INVARIANTS();
}

V-B-1. Comment gérer une violation de contrat ?▲

V-B-2. Pourquoi désactiver la vérification du contrat ?▲

int factorielle(int n)
{
        REQUIRE(n >= 0, "n positif");
        if(n > 1)
                return n * factorielle(n-1)
        else
                return 1;
}

V-B-3. Macros utiles▲

#ifndef CONTRACTS_H
 
#define CONTRACTS_H
 
#ifdef CONTRACTS_USE_ABORT
  #include <stdlib.h>
  #define REQUIRE(cond,texte) if(!(cond)) abort()
  #define ENSURE(cond, texte) if(!(cond)) abort()
  #define INVARIANT(cond, texte) if(!(cond)) abort()
  #define BEGIN_INVARIANT_BLOCK(className) void _contract_check_invariants() {
  #define END_INVARIANT_BLOCK }
  #define CHECK_INVARIANTS _contract_check_invariants
#endif
 
#ifdef CONTRACTS_USE_ASSERT
  #include <assert.h>
  #define REQUIRE(cond, texte) assert(cond)
  #define ENSURE(cond, texte) assert(cond)
  #define INVARIANT(cond, texte) assert(cond)
  #define BEGIN_INVARIANT_BLOCK(className) void _contract_check_invariants() {
  #define END_INVARIANT_BLOCK }
  #define CHECK_INVARIANTS _contract_check_invariants
#endif

Le pattern NVI, pour « Non Virtual Interface », consiste à définir une interface non virtuelle à la classe, laissant les appels virtuels à des méthodes protégées. La vérification du contrat s'adapte extrêmement bien à ce pattern : du fait que l'interface est non virtuelle, le contrat sera exprimé et vérifié aussi pour les classes héritées. Les appels internes à une classe peuvent ignorer la vérification du contrat (en appelant la méthode protégée plutôt que l'interface publique). Ceci permet d'activer la vérification des contrats même sur du code release, à faible coût. Ceci règle en grande partie la limitation de notre implémentation, qui nous empêchait les instructions return en milieu de fonction. Comme l'interface n'est plus qu'un proxy qui se charge de vérifier le contrat et d'appeler une fonction membre protégée, l'écriture n'en est que très peu alourdie.

class A
{
private:
        virtual int do_f(int n);
public:
        int f(int n)
};
 
int A::do_f(int n) // cette fonction illustre le return multiple
{
        // on ne vérifie plus le contrat dans cette fonction
        if(n > 0)
                return 1/n;
        else 
                return  2/n; // la précondition n != 0 est exprimée dans l'interface publique
}
 
int A::f(int n)
{
        REQUIRE(n != 0, "n différent de 0");
        double ret = do_f(n);
        ENSURE(ret >= -2 && ret < 1, "Valeur de retour dans l'intervalle [-2, 1]");
        return ret;
}

Doxygen fournit tout ce qu'il faut pour documenter de manière claire les préconditions, postconditions et invariants de classe. Cela se fait au moyen des balises \pre, \post, \inv. Toutefois, ces informations figurant déjà dans le code, il serait à la fois redondant et source d'erreurs de les répéter.

Heureusement, Doxygen fournit la possibilité de définir des macros pour la génération de la documentation. Nous allons donc réutiliser nos macros C++, mais pour cette fois leur faire générer la documentation. Nous allons donc modifier le fichier Doxyfile afin qu'il interprète correctement les macros que nous avons écrites :

PREDEFINED =    "REQUIRE(a,b)=///\pre b" \
                                "ENSURE(a,b)=///\post b" \
                                "BEGIN_INVARIANT_BLOCK= " \
                                "BEGIN_INVARIANT_BLOCK(a)= ///\class a " \
                                "END_INVARIANT_BLOCK= " \
                                "INVARIANT(a,b)=///\invariant b"

La documentation de nos fonctions, de nos invariants de classe, etc. est alors automatiquement prise en charge par Doxygen.

Définition : on appelle covariance le fait de, pour une fonction membre d'un objet B dérivé de A, remplacer dans sa signature le type A par le type B. On appelle contra-variance le fait de faire l'inverse.

La covariance des arguments a principalement été introduite et popularisée afin de régler de manière élégante une problématique simple à énoncer : comparer deux objets et savoir s'ils sont égaux. Puisque pour comparer deux objets, il faut connaître leur type dynamique (en effet, deux B peuvent être égaux du point de vue d'un A, mais pas d'un B).

struct A
{
        int x;
        bool operator==(A const & other) const { return x == other.x; };
};
struct B : public A
{
        int y;
        bool operator==(B const & other) const { return x == other.x && y == other.y; }
}
 
int main()
{
        B b1, b2;
        b1.x = b2.x = 1;
        b1.y = 1;
        b2.y = 2;
        std::cout << (A) b1 == (A) b2 << " " << b1 == b2 << std::endl;
}

Le code précédent montre bien la limitation d'une approche basée sur l'opérateur d'égalité. b1 et b2 sont égaux du point de vue d'un A, mais pas d'un B. L'idée est donc de pouvoir écrire une méthode polymorphique plutôt qu'un opérateur. Ainsi, le type réel serait utilisé pour la comparaison.

struct A
{
        int x;
        virtual bool IsEqual(A const & other) const;
}
 
struct B : public A
{
        int x;
        virtual bool IsEqual(B const & other) const;
}

Bien sûr, on veut comparer un B avec d'autres B, pas avec des A, puisqu'on sait déjà que si other est un A, il est différent. D'où l'idée de permettre de redéfinir le type de l'argument.

On se heurte toutefois à un problème. On l'a vu, le type des arguments est un contrat, une précondition. Or, restreindre à un sous-type est une restriction de cette précondition. On a ici un exemple flagrant de violation de contrat. Et dans les faits, cela se traduit par des erreurs à l'exécution, indétectables par le compilateur ni même par les contrats intégrés au langage en Eiffel.

Pourtant, cela fonctionne pour this… En effet, ce n'est pas parce que l'on écrit b->func() que b n'en est pas moins un paramètre de func. Il faut alors se rappeler que nous sommes en single-dispatch, et donc que ce paramètre est un petit peu particulier. En effet, il détermine quelle fonction va être appelée à l'exécution. C'est-à-dire que, quel que soit l'endroit dans le code, la fonction exécutée sera toujours celle correspondant au type réel de b. De fait, l'appel est sûr.

Des réflexions précédentes, on peut déduire qu'un système de type autorisant les paramètres covariants en multiple-dispatch serait « sûr ». Les paramètres contravariants, quant à eux, ne posent aucun problème du point de vue des contrats. Leur utilité reste toutefois à démontrer.

La valeur de retour, elle, est une postcondition. Il est donc tout à fait sûr d'utiliser des valeurs de retour covariantes, puisque cela consiste simplement en une restriction des postconditions, ce qui est tout à fait autorisé. C'est pour cela que les valeurs de retour covariantes sont autorisées en C++. C++ étant single-dispatch, il n'autorise pas les paramètres covariants.

• Conception et programmation orientées objet - Bertrand Meyer.
• Le pattern NVI.
• Une proposition visantàajouter le support des contrats dans le langage.
• Enforcing Code Feature Requirements in C++ - Scott Meyers.
• Contract Programming 101 - Matthew Wilson.