Venant du monde C++, j'ai quelques réflexes qu'il faut que je transforme en équivalent smalltalk.
Quand on veut prévenir un autre objet d'un niveau hiérarchique inférieur (un parent par exemple), on créé une interface callback (classe abstraite pure) qu'on fait hériter par le parent, ce dernier passant un pointeur de ce type (cad lui même puisqu'il hérite) au fils qui utilise les méthode de l'interface (par ce pointeur) pour prévenir le parent.
Comment fait-on l'équivalent en smalltalk puisque le double héritage n'existe pas et que tout dérive au moins de objet ?
D'après ce que je comprends, on ne fait pas ! On appel directement la méthode et si ca matche, ca ira la ou il faut ! (sinon on aura un 'messageNotUnderstood')
Cad par exemple Dans le fils (qui est un héritier de morph): action owner moncallback
Dans le père: moncallback ...
Les méthodes à 'hériter' sont définies par un contrat tacite entre les classes, non ? Il n'y a pas plus explicite ?
Merci Vincent
_____________________________________________________________________________ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
Salut Vincent,
j'aimerai bien t'aider, mais je n'ai absolument rien compris :-). Pourrais-tu donner un exemple ?
2008/8/22 Vincent Osele oselev@yahoo.fr:
Venant du monde C++, j'ai quelques réflexes qu'il faut que je transforme en équivalent smalltalk.
Quand on veut prévenir un autre objet d'un niveau hiérarchique inférieur (un parent par exemple), on créé une interface callback (classe abstraite pure) qu'on fait hériter par le parent, ce dernier passant un pointeur de ce type (cad lui même puisqu'il hérite) au fils qui utilise les méthode de l'interface (par ce pointeur) pour prévenir le parent.
Comment fait-on l'équivalent en smalltalk puisque le double héritage n'existe pas et que tout dérive au moins de objet ?
D'après ce que je comprends, on ne fait pas ! On appel directement la méthode et si ca matche, ca ira la ou il faut ! (sinon on aura un 'messageNotUnderstood')
Cad par exemple Dans le fils (qui est un héritier de morph): action owner moncallback
Dans le père: moncallback ...
Les méthodes à 'hériter' sont définies par un contrat tacite entre les classes, non ? Il n'y a pas plus explicite ?
Merci Vincent
_____________________________________________________________________________Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
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 ?
Merci, Vincent
2008/8/22 Vincent Osele oselev@yahoo.fr:
Venant du monde C++, j'ai quelques réflexes qu'il faut que je transforme en équivalent smalltalk.
Quand on veut prévenir un autre objet d'un niveau hiérarchique inférieur (un parent par exemple), on créé une interface callback (classe abstraite pure) qu'on fait hériter par le parent, ce dernier passant un pointeur de ce type (cad lui même puisqu'il hérite) au fils qui utilise les méthode de l'interface (par ce pointeur) pour prévenir le parent.
Comment fait-on l'équivalent en smalltalk puisque le double héritage n'existe pas et que tout dérive au moins de objet ?
D'après ce que je comprends, on ne fait pas ! On appel directement la méthode et si ca matche, ca ira la ou il faut ! (sinon on aura un 'messageNotUnderstood')
Cad par exemple Dans le fils (qui est un héritier de morph): action owner moncallback
Dans le père: moncallback ...
Les méthodes à 'hériter' sont définies par un contrat tacite entre les classes, non ? Il n'y a pas plus explicite ?
2008/8/24 Vicnet oselev@yahoo.fr:
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.
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 oselev@yahoo.fr:
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 Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Bonjour,
Il y a une manière d'expliciter les contrats. Il s'agit de recourir au tests SUnit.
Noury On 24 août 08, at 12:24, Jean-François LEFEVRE wrote:
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 oselev@yahoo.fr:
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 Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
-- *Jean-François LEFEVRE* Architecte Senior +33 (0)6 80 38 01 29 jflefevre@sqli.com mailto:jflefevre@sqli.com 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 Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury
European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------
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
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 :)
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 Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Le 11 septembre 2008 19:58, stephane ducasse stephane.ducasse@free.fr a écrit :
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 :)
Le chapitre 7 du SBE est sur les tests unitaires en effet. Disponible en ligne sur : http://www.squeakbyexample.org/fr Tu peux télécharger la version pdf mais également acheter le livre en ligne sur lulu.com :
http://www.lulu.com/content/2409980
Le livre est vendu 16.70 euros. Ce n'est pas cher (on gagne que 5 euros par exemplaire), n'hésitez pas à l'acheter pour soutenir de futures traductions. Il y a eu plus de 2500 téléchargements du livre mais seulement 37 exemplaires vendus ! Merci !
squeak-fr@lists.squeakfoundation.org
-
Damien Cassou -
Jean-François LEFEVRE -
Noury Bouraqadi -
Serge Stinckwich -
stephane ducasse -
Vicnet -
Vincent Osele