Discussion :

[white_tentacle]

Bonjour,

J'ai écrit un article sur la programmation par contrat et sa mise in œuvre en C++. Ça se trouve ici :

http://julien-blanc.developpez.com/a...rat_cplusplus/

Ce tutoriel vise à présenter de manière relativement concise les objectifs de la conception et de la programmation par contrat, ainsi que les techniques de mise en oeuvre dans le langage C++. Le lecteur est supposé connaître les bases de la programmation, de l'approche orientée objet et de la généricité. Ce tutoriel s'adresse donc à des développeurs de niveau moyen à expérimenté.

Vos remanques sont évidemment les bienvenues, et bonne lecture.

[Mat007]

Salut,

(en anglais, on utilise le terme plus heureux de design by contracts)

C'est design by contract sans le s.

Sinon dans l'exemple de 5.3 il y a do_f qui se transforme en _f.

MAT.

[white_tentacle]

Corrigé, merci

[3DArchi]

Bonjour,
En tout cas, c'est un super article
La programmation par contrat est une démarche qui permet de faire des codes plus simples en clarifiant les responsabilités. Ses principes se heurtent trop souvent à l'habitude de la programmation défensive et c'est dommage.
Il y a peu de littérature en français et sur le net sur ce sujet. On a enfin un document qui précise bien la démarche.

[Lavock]

Très bon tutoriel, merci (surtout que suite à la discussion levée par Archi je n'été pas arriver à assez me renseigner à mon gout)!
Par contre :

laissant les appels virtuels à des méthodes protégées.

Ca ne serait pas plutôt privées ? Même si ce n'est pas ce que tu voulais dire, je trouve que "protégées" ça fait trop pensées à "protected".

[white_tentacle]

Par contre :

laissant les appels virtuels à des méthodes protégées.

Ca ne serait pas plutôt privées ? Même si ce n'est pas ce que tu voulais dire, je trouve que "protégées" ça fait trop pensées à "protected".

Je ne suis pas fan de la visibilité privée, donc j'entendais bien protected (et puis, j'ai été longtemps persuadé qu'une méthode privée n'était pas redéfinissable, ce qui est faux mais ça crée des habitudes). Ici, je trouve intéressant de laisser la possibilité à l'auteur d'une classe dérivée d'appeler directement la méthode qui ne vérifie pas le contrat. Mais je suis d'accord que les deux points de vue se défendent. Le NVI tel que décrit au départ par James Kanze (je suis d'ailleurs désolé pour lui, mais je n'ai pas trouvé d'article de sa part à citer, seulement de nombreux messages épars sur des newsgroups, si quelqu'un en connaît un, je le rajouterai volontiers) utilise effectivement la visibilité privée. Son argument est que le fait que le client hérite de la classe ne change rien au fait que ce soit un client, et donc, qu'on doit vérifier le contrat si la vérification est active pour tous.

L'idee est juste de creer une instance en debut de fonction/methode qui effectuera les checks lors de sa destruction (et donc a la fin de la fonction)

C'est tentant, mais malheureusement, ça ne fonctionne pas. En effet, les postconditions ne sont pas garanties en cas d'exception, donc les vérifier dans un destructeur n'est pas faisable. C'est éventuellement envisageable pour les invariants, suivant le comportement qu'on souhaite avoir en cas d'exception.

[thoratou]

Juste pour ton probleme avec le probleme du return multiple, j'aurais peut etre une solution (l'exemple est moche mais c'est l'idee qui compte ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
int A::f(int n){
   int ret;
   ENSURE_RET(int, ret, (*_r) >= -2 && (*_r) < 1, "Valeur de retour dans l'intervalle [-2, 1]");
   if(n > 0){
      ret = 1/n;
      return ret;
   }
   else{
      ret = 2/n;
      return ret;
   }
}

avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#define ENSURE_RET(type, value, cond, text) \
   class EnsureRet{ \
      EnsureRet(type* value) \
         :_r(value) \
      {} \
 \
      ~EnsureRet(){ \
         ENSURE(cond, text); \
      } \
 \
      type* _r; \
   } ensure_ret_instance(&value);

L'idee est juste de creer une instance en debut de fonction/methode qui effectuera les checks lors de sa destruction (et donc a la fin de la fonction)

Apres l'idee peut etre largement amelioree