Equivalent des interfaces callback du C++

> 2008/8/24 Vicnet <[hidden email]>:
>  
>> Bonjour,
>>
>> Damien Cassou a écrit :
>>    
>>> j'aimerai bien t'aider, mais je n'ai absolument rien compris :-).
>>> Pourrais-tu donner un exemple ?
>>>      
>> Oui voila en C++:
>>
>> class I {
>>        virtual void callback() = 0;
>> };
>>
>> class A : public virtual I
>> {
>>        virtual void callback() {
>>                std::cout << "Je suis prévenu maintenant !";
>>        }
>> };
>>
>> class B
>> {
>>        Enfant(I* i) : _i(i) { }
>>        void evennement() {
>>                _i->callback();
>>        }
>>        I* _i;
>> };
>>
>> A a;
>> B b(a);
>> b.evennement();
>>
>> a est prévenu d'un évennement par un b sans que b ne connaisse tout de a. A
>> et B sont découplés.
>>
>> Zn java, il y a directement le mot clef interface.
>>
>> Il y a un 'contrat' I entre les deux que chacun doit respecter/utiliser.
>>
>> En smalltalk, le 'contrat' semble implicite. Voici ce que je fais en squeak
>> (peut etre faudrait-il mettre les methode sous la forme Object>>methode mais
>> je ne suis pas sur de la syntaxe):
>>
>> Object subclass: #A
>>        ...
>> callback
>>        Transcript print: "Je suis prévenu maintenant !"; cr.
>>
>> Object subclass: #B
>>        instanceVariableNames: 'i'
>>        ...
>> evennement
>>        i callback.
>>
>> |a b|
>> a := A new.
>> b := B new.
>> b evennement. "a est prévenu !"
>>
>> a est prévenu mais le contrat n'est pas matérialisé par un objet.
>> Quand on implémente A, on peut oublier de déclarer callback si personne ne
>> nous le dit !
>>
>> Est-ce la bonne façon de faire ?
>>    
>
> Oui, c'est la bonne façon de faire en général je pense.
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Squeak-fr mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
>  

> Bonjour,
>
> Comme tu le dis si bien, la notion d'interface est implicite et le  
> contrat doit au mieux être exprimé dans les commentaires de méthode  
> ou de classe.
> Souvent le contrat est exprimé à l'aide d'une classe abstraite et  
> les méthodes obligatoires sont définies de manière abstraite (self  
> subclassResponsibility).
> Ce n'est pas toujours possible (quand tu as besoin d'hériter d'autre  
> chose) et dans ce cas on peut effectivement avoir des  
> messageNotUnderstand si
> on n'a pas respecté le contrat.
>
> Cordialement,
> Jean-François
>
> Damien Cassou a écrit :
>> 2008/8/24 Vicnet <[hidden email]>:
>>
>>> Bonjour,
>>>
>>> Damien Cassou a écrit :
>>>
>>>> j'aimerai bien t'aider, mais je n'ai absolument rien compris :-).
>>>> Pourrais-tu donner un exemple ?
>>>>
>>> Oui voila en C++:
>>>
>>> class I {
>>>       virtual void callback() = 0;
>>> };
>>>
>>> class A : public virtual I
>>> {
>>>       virtual void callback() {
>>>               std::cout << "Je suis prévenu maintenant !";
>>>       }
>>> };
>>>
>>> class B
>>> {
>>>       Enfant(I* i) : _i(i) { }
>>>       void evennement() {
>>>               _i->callback();
>>>       }
>>>       I* _i;
>>> };
>>>
>>> A a;
>>> B b(a);
>>> b.evennement();
>>>
>>> a est prévenu d'un évennement par un b sans que b ne connaisse  
>>> tout de a. A
>>> et B sont découplés.
>>>
>>> Zn java, il y a directement le mot clef interface.
>>>
>>> Il y a un 'contrat' I entre les deux que chacun doit respecter/
>>> utiliser.
>>>
>>> En smalltalk, le 'contrat' semble implicite. Voici ce que je fais  
>>> en squeak
>>> (peut etre faudrait-il mettre les methode sous la forme  
>>> Object>>methode mais
>>> je ne suis pas sur de la syntaxe):
>>>
>>> Object subclass: #A
>>>       ...
>>> callback
>>>       Transcript print: "Je suis prévenu maintenant !"; cr.
>>>
>>> Object subclass: #B
>>>       instanceVariableNames: 'i'
>>>       ...
>>> evennement
>>>       i callback.
>>>
>>> |a b|
>>> a := A new.
>>> b := B new.
>>> b evennement. "a est prévenu !"
>>>
>>> a est prévenu mais le contrat n'est pas matérialisé par un objet.
>>> Quand on implémente A, on peut oublier de déclarer callback si  
>>> personne ne
>>> nous le dit !
>>>
>>> Est-ce la bonne façon de faire ?
>>>
>>
>> Oui, c'est la bonne façon de faire en général je pense.
>>
>>  
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Squeak-fr mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
>>
>
>
> --
> *Jean-François LEFEVRE*
> Architecte Senior
> +33 (0)6 80 38 01 29
> [hidden email] <mailto:[hidden email]>
> 268, avenue du Président Wilson 93210 LA PLAINE-SAINT-DENIS
> Std : +33 1 55 93 26 00 - Fax : +33 1 55 93 26 01
> *"SQLI Consulting, l'expert du conseil IT"*
> www.sqli.com <http://www.sqli.com>
>
> /----------------------------------------------------------------------------------
> Ce message et toutes les pièces jointes (ci-après le "message") sont  
> confidentiels et établis à l'intention exclusive de ses destinataires.
> Toute utilisation ou diffusion non autorisée est interdite. Tout  
> message électronique est susceptible d'altération.
> ----------------------------------------------------------------------------------
> /
>
>
> _______________________________________________
> Squeak-fr mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
>

> Bonjour,
>
> Noury Bouraqadi a écrit :
>> Il y a une manière d'expliciter les contrats. Il s'agit de recourir  
>> au tests SUnit.
>
> J'ai cherché des infos sur SUnit mais je n'ai pas trouvé de trucs  
> clais pour moi.
> D'après le nom, j'imagine un framework de test unitaire, et la je ne  
> vois pas trop comment on explicite les contrats avec.

> Bien sur, si on teste toutes les méthodes de la classe dérivée, on  
> va pouvoir voir les trous du contrat. Mais cela ne valide pas  
> implicitement le contrat. C'est l'utilisateur de la classe qui doit  
> tout vérifier.
>
> Ma question se pose par exemple avec une hierarchie d'héritage  
> importante, développé par des tiers dont on ne maitrise pas tout...
>
> a+
> Vicnet
>
> _______________________________________________
> Squeak-fr mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
>

>
> On Sep 11, 2008, at 6:07 PM, Vicnet wrote:
>
>> Bonjour,
>>
>> Noury Bouraqadi a écrit :
>>>
>>> Il y a une manière d'expliciter les contrats. Il s'agit de recourir au
>>> tests SUnit.
>>
>> J'ai cherché des infos sur SUnit mais je n'ai pas trouvé de trucs clais
>> pour moi.
>> D'après le nom, j'imagine un framework de test unitaire, et la je ne vois
>> pas trop comment on explicite les contrats avec.
>
> comment fais-tu a ne pas trouver
>                http://stephane.ducasse.free.fr/Books.html en bas Sunit 30
> meme ne francaise
>                et http://www.squeakbyexample.org/fr
>
> Si on ecrit les livres mais que les gens ne les lisent pas :)