Version imprimable
Je viens de découvrir cette approche de la programmation qui consiste à fixer des contrats (par assertion) sur des méthodes et/ou objets. Un bon article là-dessus : http://www.logilab.fr/publications/contrats_et_qualite.html
J'aimerais savoir si l'un d'entre vous a déjà pratiqué ce type de programmation.
Quels avantages en avez-vous tiré ?
Y a-t-il des inconvénients, des défauts ?
Quelles méthodes d'assertions (en C++) avez-vous utilisé ?
Merci de votre feedback.
bonjour,
j'ai effectivement utilisé la programmation par contrat lors de mes étude à l'IUT avec le langage Java. On mettait les pre/post conditions et invariant dans la javadoc et on passait par une phase de pré-compilation. On avait aussi survolé eiffel mais là je ne m'en rappel plus :(
Si à l'époque le désavantage était la précompilation, maintenant Sun à intégré les assertions directement dans java.
Je pense que c'est une bonne chose même si je ne l'utilise pas :oops:
Je ne vois pas trop de mauvais coté. Ca facilite le codage car pour chaque méthode tu dois définir l'état de l'objet avant et après son exécution (pre/post condition). Ca oblige a pousser plus loin sa réflexion sur l'action des méthode et en plus ça rend ton application plus robuste :)
Il faudrait que je m'y remette tient :)
Idem, avec un pré compilateur développer en python par un professeur.Citation:
bonjour,
j'ai effectivement utilisé la programmation par contrat lors de mes étude à l'IUT avec le langage Java. On mettait les pre/post conditions et invariant dans la javadoc et on passait par une phase de pré-compilation.
Ce système est pratique pour le développement de Frameworks.
Notons toutefois qu'avec un bon code, les posts conditions doivent disparaitre (elles ne sont là que pour les tests).
On a aussi utiliser les tests unitaires qui sont écris dans un commentaire en fin de classe. Ils sont compilés avec le même pré compilateur. Ces tests permettent de vérifier que la classe à un fonctionnement cohérent.
Les contrats et le tests unitaires doivent êtres écrits avant le code et de préférence par une autre personne que le développeur.
J'espère qu'un jour sun proposera des tags pour les contrats en Java (l'instruction assert c'est bien, mais elle n'est utile que dans les posts conditions)...
Les avantages sont nombreux et se résument grosso modo à une meilleure robustesse de l'application.
Cette approche permet de détecter les erreurs de conception/développement, mais aussi les erreurs liées à l'exécution et sur lesquelles nous n'avons pas vraiment de contrôle.
Côté désavantage, il y a la croyance que cela demande plus de temps. Lors du développement, c'est sûr. Mais c'est du temps que l'on va gagner sur les phases de correction. L'un dans l'autre, je ne trouve pas que cela soit une mauvaise chose.
Tout comme le Java, et plein d'autres langages [1], le C++ n'offre pas de support en natif [2] pour la programmation par contrats (ppc) . En revanche, son ouverture (pas d'esprit, mais) de syntaxe donne accès à la ppc sans passer par un préprocesseur ou tout autre outil externe au langage -- à ma connaissance, les assertions ne permettent pas de spécifier pré- et post-conditions sur les interfaces en Java.
Typiquement, on va mettre en oeuvre cela en C++ (quand on en a besoin) en ne définissant non pas une interface, mais un contrat via des classes abstraites.
Maintenant, dans les test sur les pré- et post-conditions, il y a plein de façons possibles pour procéder :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19struct contract_A { void f (P p) { ... vérif des pré-conditions f_(p); ... vérif des post-conditions } private: virtual void f_(P) = 0; }; struct c : contrat_A, contrat_B, ... // héritage multiple de contrats { private: /*virtual*/ void f_(P p) { ... code ... } ... };
- lever une exception (toujours, si en _DEBUG, si ...)
- arréter le programme et proposer de le débugger (car erreur critique)
- afficher un message d'erreur, logguer le problème et sortir proprement
- ...
Si on veut se laisser le choix entre toutes ces techniques (quand on développe une bibliothèque), on peut envisager d'utiliser des polices d'erreurs ; en "templatisant" les classes contrats.
Andrei Alexandrescu a écrit divers articles sur des assertions avancées (bien plus pratiques que std::assert) consultables en ligne sur le site du C/C++ Users Journal, et référencés depuis son site web. Le rapport avec la ppc étant le comment les invariants peuvent être testés.
[1] Je connais au moins D et Eiffel qui permettent la ppc en natif.
[2] Le compilateur C++ de Digital Mars propose facilité propriétaire pour la ppc -- D, c'est aussi eux.
Question coding en C++, si les pré-conditions et les post-conditions peuvent être implémentées par des assertions, comment peut-on coder les invariants ?
Existe-t-il des librairies C++ implémentant ces notions de programmation par contrats ?
Merci.
L'invariant est un truc qui doit être valide avant, pendant et après. Autant si le avant et après est facile à traiter, le pendant est plus complexe. Faut-il réaliser les tests après chaque opérations ? En pratique, c'est difficilement faisable et fort couteux.
Je pense que sur le même modèle que ce que j'ai présenté, c'est au codeur de savoir à quel moment il convient de tester tel ou tel invariant.
Pour ce qui est de l'existance de bibliothèques ... il n'y en a pas vraiment.
Perso je jongle entre le code type présenté (avec un bon éditeur de texte /EDI/case-tool c'est tout de suite plus transparent) plus haut, SmartAssert (pour les assertions avancées) et une bibliothèque pour les logs.
j'ai l'impression que c'est le rendez vous des anciens de l'IUT de Vannes ici...
pour les pre/post conditions on utilisait en effet un framwork vraiment bien foutu. en effet on mettait les pre/post condition dans les tags javadoc des methodes, l'invariante de la classes dans la javadoc de la classe et en fin de classe les tests unitaires.
mais la ou c'etait vraiment puissant c'est qu'on pouvait utiliser les mecanismes d'heritages pour ces test et contrats.
en gros si on créait une interface avec des contrats et des tests, le preprocesseur les reportait sur l'ensemble des sous classes. ca permettait des test de non regression et tout le tintouin. idem pour les invariant et autre.
grace a ca mecanisme on peut vraiment gagner du temps car une fois la base d'un framework mise en place, il ne reste que tres peut de pre/post conditions a écrire vu que tout les contrat "standard" on été ecrit dans les classes dont on herite...
[EDIT] pout plus de renseignement regardez a STclass sous google