Sebastien Cesbron wrote:
> Je vais essayer d'�tre plus clair avec un exemple.
>
> Supposons le code suivant :
>
> public class Toto
> {
> public String getNom(Titi aTiti)
> {
> if (aTiti != null)
> {
> return aTiti.getNom();
> }
> else
> {
> throw ...
> }
> }
> }
>
> Le fait
> en utilisant iContract on doit je pense avoir le code suivant :
>
> public class Toto
> {
> /**
> * @pre aTiti != null
> **/
> public String getNom(Titi aTiti)
> {
> return myTiti.getNom();
> }
> }
>
> Du coup lorsque l'on instrumentalise on a la m�me chose mais lorsque l'on supprime
>la pr�-condition, si on passe null en param�tre le comportement devient impr�visible.
> Bien s�r dans un mode de fonctionnement normal le contrat sp�cifie que l'on ne doit
>pas passer null mais ce qui me g�ne c'est qu'il est impossible d'avoir une couverture
>de test compl�te et donc on ne peut pas garantir l'absence d'utilisation anormale de
>getNom.
si justement, puisque c'est le code instrumente qui va lever l'exception
pour toi!!!!
avec un message du genre assertion failed....
>
> La question que l'on me pose donc lorsque j'essaie de mettre en place la
>programmation par contrat est : quel est l'avantage des pr�conditions par rapport �
>un test syst�matique qui l�ve une exception m�tier.
il est clair, t'as le meme resultat, en ecrivant moins de code, donc
code plus compact, de plus ce code peut etre genere par un AGL puisque
du coup tu integres dans ton modele les invariants... au lieu de le
camoufler dans l'implementation!!! de plus tu oublies le comportement
lors d'heritage ou tu es oblige de dupliquer tes tests, alors que la DBC
te garantit un comportement reellement objet...
Est juste un probl�me de performance ou bien y a t'il quelque chose qui m'�chappe
>
j'espere t'avoir fait comprendre que je penche pour la 2eme reponse...
Jerome
