Oui c'est sympa comme approche, hélas ça n'est pas assez mis en pratique à mon gout.
Si tu veux un bon bouquin sur le sujet je te conseille "Design by Contract by Example" de Richard Mitchell et Jim McKim (edition Addison Wesley). Ça présente très bien les notions, et le gros plus, c'est qu'il apporte une "méthode" pragmatique aidant à définir et écrire les contrats. Cette méthode est basée sur la distinction des différents types de méthodes : les requêtes de base, les dérivés et les commandes (modifiant l'état de l'objet).
Autrement, il faut savoir que si les contrats sont apparus dans le langage Eiffel, il existe plein de bibliothèques/plugins/bidouilles pour presque tous les autres langages. Je peux te conseiller STclass for Java (http://web.iu-vannes.fr/docinfo/produits_locaux/stclass/java/index.(...) ), qui est un produit de l'université de Vannes et qui a comme caractérisque (de mémoire) :
- Les contrats sont écris dans les commentareis comme une extension de javadoc (mot clès @pre, @post, @inv);
- Ils sont écrit dans une syntaxe proche de Java (ajout des instruction 'forall' et 'exists', et possibilité de faire référence à une valeur ancienne dans une postcondition en y concatenant '@pre' (ex: @post size=size@pre+1)
- Gére l'héritage de contrats à partir des classes et/ou interface mères. C'est très pratique et propre surtout
- possibilité lors de la compilation de prendre ou non les contrats (ou que les pré ou post conditions). En fait on utilise l'outil javacst pour interprété les contrats et les ajouter dans le source Java avant de compiler ces dernières avec javac.
- permet d'ajouter la notion d'autotest (à la Junit) embarqués dans les comentaires, à utiliser avec JMutator (donc je ne retrouve plus de trace :/) pour vérifier la couverture de code (où il y a plein de mutants vivant, c'est que ça manque de tests/contrats :) et pour améliorer les contrats/tests (et le code en même temps :).
Voila en gros ce que je peux dire sur STclass, j'ai surement oublié plein de truc, j'avais entendu parler d'un plugin pour Eclipse mais j'ai pas été voir ça depuis un certains temps. Pour ce qui est des alternatives, tu trouveras plein de choses en cherchant un peu (icontract ...).
Pour finir, le mieux c'est une fois avoir écrit tes spécifications par exemple avec UML et OCL, tu écris les squelettes de tes classes/interfaces en y mettant que les signatures de tes méthodes avec les pré/postcondition qui vont bien ainsi que les suites d'autotests. Ensuite tu commences à développer le code des méthodes, et dès que tu as mis en place assez de méthodes pour exectuer une 'feature' , tu lances la suite de test correponsdante. Bien sûr tu auras des erreurs (contrat que se lève, résultat du test pas bon, exception levée ...), mais justement elles te permettront de consolider des contrats/tests/codes.
[^] # Re: Design by Contract
Posté par pifou . En réponse au journal Design by Contract. Évalué à 1.
Si tu veux un bon bouquin sur le sujet je te conseille "Design by Contract by Example" de Richard Mitchell et Jim McKim (edition Addison Wesley). Ça présente très bien les notions, et le gros plus, c'est qu'il apporte une "méthode" pragmatique aidant à définir et écrire les contrats. Cette méthode est basée sur la distinction des différents types de méthodes : les requêtes de base, les dérivés et les commandes (modifiant l'état de l'objet).
Autrement, il faut savoir que si les contrats sont apparus dans le langage Eiffel, il existe plein de bibliothèques/plugins/bidouilles pour presque tous les autres langages. Je peux te conseiller STclass for Java (http://web.iu-vannes.fr/docinfo/produits_locaux/stclass/java/index.(...) ), qui est un produit de l'université de Vannes et qui a comme caractérisque (de mémoire) :
- Les contrats sont écris dans les commentareis comme une extension de javadoc (mot clès @pre, @post, @inv);
- Ils sont écrit dans une syntaxe proche de Java (ajout des instruction 'forall' et 'exists', et possibilité de faire référence à une valeur ancienne dans une postcondition en y concatenant '@pre' (ex: @post size=size@pre+1)
- Gére l'héritage de contrats à partir des classes et/ou interface mères. C'est très pratique et propre surtout
- possibilité lors de la compilation de prendre ou non les contrats (ou que les pré ou post conditions). En fait on utilise l'outil javacst pour interprété les contrats et les ajouter dans le source Java avant de compiler ces dernières avec javac.
- permet d'ajouter la notion d'autotest (à la Junit) embarqués dans les comentaires, à utiliser avec JMutator (donc je ne retrouve plus de trace :/) pour vérifier la couverture de code (où il y a plein de mutants vivant, c'est que ça manque de tests/contrats :) et pour améliorer les contrats/tests (et le code en même temps :).
Voila en gros ce que je peux dire sur STclass, j'ai surement oublié plein de truc, j'avais entendu parler d'un plugin pour Eclipse mais j'ai pas été voir ça depuis un certains temps. Pour ce qui est des alternatives, tu trouveras plein de choses en cherchant un peu (icontract ...).
Pour finir, le mieux c'est une fois avoir écrit tes spécifications par exemple avec UML et OCL, tu écris les squelettes de tes classes/interfaces en y mettant que les signatures de tes méthodes avec les pré/postcondition qui vont bien ainsi que les suites d'autotests. Ensuite tu commences à développer le code des méthodes, et dès que tu as mis en place assez de méthodes pour exectuer une 'feature' , tu lances la suite de test correponsdante. Bien sûr tu auras des erreurs (contrat que se lève, résultat du test pas bon, exception levée ...), mais justement elles te permettront de consolider des contrats/tests/codes.