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.
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. Est juste un probl�me de performance ou
bien y a t'il quelque chose qui m'�chappe
Seb
On Mon, 04 Feb 2002 14:31:11 +0100
Jerome Moliere <[EMAIL PROTECTED]> wrote:
>
>
> Sebastien Cesbron wrote:
>
> > Salut � tous,
> >
> > J'aimerais lancer un d�bat sur l'utilit� de la programmation par contrat et son
>instrumentalisation en Java
> >
> > En fait je suis en train de regarder icontract. Son int�gration avec Ant semble
>int�ressante mais il y deux points que j'aimerais �claircir :
> >
> > 1 - Est ce que quelqu'un conna�t des liens int�ressants qui expliquent la th�orie
>de la programmation par contrat. J'ai le bouquin de Bertrand Meyer mais je n'ai pas
>eu trop le temps de le parcourir. J'aurais aim� trouv� des tutoriaux plus succints si
>possible. Ma pr�ocuppation principale est la suivante : vu que l'on instrumentalise
>le code avec des pr� conditions style (argument != null), que se passe t'il sur du
>code non instrumentalis� si la pr� condition est viol�e, doit on en plus de la
>pr�condition refaire le test nous m�me ou faut il garder les pr�-conditions sur les
>classes sensibles et consid�rer pour les autres que la pr�-condition est toujours
>respect�e. Ce qui me g�ne l� dedans, c'est que le code non instrumentalis� me semble
>tr�s fragile.
>
>
> t'as la meilleure des sources pourquoi aller chercher ailleurs ?
>
> je ne comprends pas trop ta question, le code non instrumente est un outil
>permettant de faire telle
>
> ou telle chose, le code instrumente ajoute le contrat , le cadre
> delimitant les responsabilites/engagements dans le dialogue
> client/serveur...
>
>
> >
> > 2 - Pour une programmation par contrat en Java j'ai regard� iContract : est ce un
>bon choix, avez vous des retours d'exp�rience dessus ou sur un autre outil qui serait
>mieux. Je me rappelle d'avoir vu passer des messages sur la liste il n'y a pas trop
>longtemps sur un outil de ce type mais je ne me rappelle plus si c'�tait iContract ou
>autre chose et je n'arrive pas � remettre la main sur le message dans la
>pseudo-archive. Il faut dire que je n'ai pas trop cherch� car je me rappelle qu'�
>l'�poque les gens commencaient � l'utiliser et les retours d'exp�riences �taient
>faible. Je me dis que maintenant ils seront peut �tre plus nombreux.
> >
> c'est le meilleur des outils que je connaisse et ce entre autre via la task
>optionelle pour ANT....
>
> mais bon il en existe d'autres, mais ce ne sont que des outils, qui ne
> doivent pas te faire oublier l'essentiel....
>
> Jerome
>
> PS:
> ravi de ce thread que j'espere enrichissant
>
>
>
______________________________________________________________________________
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
