01-08-2013, 10:17 PM
C'est compliqué pour rien.
Ta bibliothèque expose une fonction map. Tu passes un callback qui reçoit un objet de type Livre et qui renvoie un objet de type Livre. Si ta fonction renvoie une référence, la bibliothèque la refuse. Si ta fonction renvoie autre chose qu'un Livre, la bibliothèque la refuse.
Au sein de ta fonction, tu peux faire ce que tu veux à ton bouquin, c'est une copie. La bibliothèque s'en fout. Ce qu'elle veut c'est que tu lui renvoie un livre qui remplacera le précédent.
Parce que au sein de ton objet, ta bibliothèque va faire des contrôles sur ce que ta fonction lui renvoie, c'est ça qui est masqué de l'extérieur.
Évidemment, ça oblige à faire des copies. Mais travailler avec des données non mutables est beaucoup plus simple. Tu as raison en disant que ça sera peut-être moins rapide, mais ça sera aussi beaucoup plus simple. Et en comparaison du temps qu'il faut pour traduire un livre, les temps de copie sont négligeables.
Sinon avec des méthodes comme toutTraduire(), il te faudra comme je le disais agrandir ta classe de façon incontrôlée.
Pour l'héritage ça peut être sympa. Sauf que ta bibliothèque elle sera peut être déjà instanciée quand tu voudras traduire. Donc le plus logique serait d'avoir une classe qui fait l'interface entre les fonctionnalités de traduction et la bibliothèque. Si elle veut pouvoir travailler sur les livres de la bibliothèque il faudra bien qu'elle itère dessus si on utilise un décorateur. On on peut utiliser une classe friend sauf qu'il faudra contrôler la "correctitude" des données dans chaque friend qui voudra pouvoir toucher aux données en plus de les déclarer friend dans la classe bibliothèque ...
Non vraiment je ne suis pas convaincu. Encore en ruby tu peux facilement patcher une classe ce qui nous rendrait heureux tous les deux
On parle ici d'une collection. Un objet bien fait devrait gérer ses billes, rien de plus. Dans mon modèle on ne te demande pas de comprendre comment serait faite l'itération, ni le reste de la documentation de l'objet. Simplement, au lieu de te dire que tu as cette interface :
Tu as celle-ci :
Ensuite ça ne change rien.
Heu sinon j'ai 27 balais je ne comprends pas trop pourquoi tu dis ça. De toute façon l'avenir c'est le Functional Programming :p
N'empêche on pourrit bien le topic.
Ta bibliothèque expose une fonction map. Tu passes un callback qui reçoit un objet de type Livre et qui renvoie un objet de type Livre. Si ta fonction renvoie une référence, la bibliothèque la refuse. Si ta fonction renvoie autre chose qu'un Livre, la bibliothèque la refuse.
Au sein de ta fonction, tu peux faire ce que tu veux à ton bouquin, c'est une copie. La bibliothèque s'en fout. Ce qu'elle veut c'est que tu lui renvoie un livre qui remplacera le précédent.
Parce que au sein de ton objet, ta bibliothèque va faire des contrôles sur ce que ta fonction lui renvoie, c'est ça qui est masqué de l'extérieur.
Évidemment, ça oblige à faire des copies. Mais travailler avec des données non mutables est beaucoup plus simple. Tu as raison en disant que ça sera peut-être moins rapide, mais ça sera aussi beaucoup plus simple. Et en comparaison du temps qu'il faut pour traduire un livre, les temps de copie sont négligeables.
Sinon avec des méthodes comme toutTraduire(), il te faudra comme je le disais agrandir ta classe de façon incontrôlée.
Pour l'héritage ça peut être sympa. Sauf que ta bibliothèque elle sera peut être déjà instanciée quand tu voudras traduire. Donc le plus logique serait d'avoir une classe qui fait l'interface entre les fonctionnalités de traduction et la bibliothèque. Si elle veut pouvoir travailler sur les livres de la bibliothèque il faudra bien qu'elle itère dessus si on utilise un décorateur. On on peut utiliser une classe friend sauf qu'il faudra contrôler la "correctitude" des données dans chaque friend qui voudra pouvoir toucher aux données en plus de les déclarer friend dans la classe bibliothèque ...
Non vraiment je ne suis pas convaincu. Encore en ruby tu peux facilement patcher une classe ce qui nous rendrait heureux tous les deux
Citation :On n'est peut-être pas de la même génération (vive les jeunots de 22 ans!), mais je préfère un objet dont je ne sais rien mais à qui je peux demander "bibliotheque.toutTraduire()" plutôt qu'un objet pour lequel je dois itérer sur son contenu (donc, je dois connaitre toute la documentation de cet objet plus celle de son contenu).
On parle ici d'une collection. Un objet bien fait devrait gérer ses billes, rien de plus. Dans mon modèle on ne te demande pas de comprendre comment serait faite l'itération, ni le reste de la documentation de l'objet. Simplement, au lieu de te dire que tu as cette interface :
Code :
toutTraduire (String language)Tu as celle-ci :
Code :
replaceBooks ( (Book -> Book) callback)Ensuite ça ne change rien.
Heu sinon j'ai 27 balais je ne comprends pas trop pourquoi tu dis ça. De toute façon l'avenir c'est le Functional Programming :p
N'empêche on pourrit bien le topic.