On Mon, 04 Feb 2002 16:16:22 +0100
Jerome Moliere <[EMAIL PROTECTED]> wrote:
>
>
> 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...
Le code instrument� va lever l'exception je suis d'accord avec toi mais est ce que tu
utilises ensuite ce code instrument� en version de production ?
Si oui, ok le r�sultat est le m�me bien qu'en terme de retour utilisateur, les
messages de type assertion failed sont peu explicites mais bon, vu qu'il s'agit alors
d'un bug c'est normal.
Par contre quid d'une version non instrument�e. Dans ce cas, les v�rifications ne sont
pas g�n�r�es, on a alors une version qui ne contr�le rien. Je trouve cela dangereux.
La r�ponse est peut �tre comme tu sembles le sugg�rer dans ton message de ne jamais
d�sactiver les contr�les des pr�/post conditions.
>
> >
> > 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
>
Je suis d'accord avec toi que tu d�finis ces conditions plus t�t ce qui est mieux par
contre je ne saisis pas la diff�rence au niveau de l'h�ritage, peux tu �tre plus
pr�cis stp.
Promis c'est mes derni�re questions
Seb
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
