03-08-2013, 01:50 AM
Pour la traduction, j'opterai alors pour:
- Si on utilise le Conteneur, une méthode ".traduction" dans la classe Livre, méthode chargée de faire la traduction du Livre, et le code utilisateur doit donc itérer sur chaque élément du conteneur pour le traduire (donc, "on se retape la boucle for à chaque fois")
- Si on passe par la bibliothèque, celle-ci implémente une méthode "traduire()" qui se charge de traduire la bibliothèque entière (pas forcément Livre à Livre donc, je m'en fous de comment elle traduis)
Pour le Erlang, il va falloir que je prenne le temps de comprendre le fonctionnement... Pour le 1er code, si j'ai bien suivit, la bibliothèque est effectivement un "bête" conteneur, donc j'ai pas de problème avec ça, et ça me va.
En revanche, dans le 2nd code (si je le comprend bien, parce que je n'en suis vraiment pas sûr), Bibliothèque a une méthode qui itère sur chacun des objets qu'elle contient, et qui exécute la fonction de traduction pour chaque objet... Or, à mon sens, cela revient donc à traiter (depuis le code utilisateur qui appelle le "replace_all_book") le conteneur dans son ensemble, et là, je trouve cela mal venu, car une même classe peut être traitée "élément par élément", comme un Conteneur classique, mais aussi "dans son ensemble", comme un objet pur. Je trouve les deux peu compatibles, et je pense que ces deux notions devraient aller dans deux classes (ou équivalent) séparées, l'une étant le conteneur des données et l'autre étant l'objet représentant l'ensemble des données de façon indissociable.
En revanche, là, Oxman je ne te comprends pas pour plusieurs raisons:
- Adapter fait la transition entre deux classes, or un Conteneur n'est pas, à mon sens et comme exposé plus haut avec tout mon "bullshit sur les atomes", un objet/classe. Donc "Bibliothèque" n'est pas un Adapter, puisque ne "passe" pas une classe (ConteneurLivre) en une autre (Bibliothèque). Ou alors, tout est objet est un Adapter...
- Tu me dis que je fais le pattern Adapter mais qu'en fait je le fais pas comme il faut... Donc en fait, je ne fais pas ce pattern... Ou, dis autrement, t'es si sûr que ça, que je fais "juste" un pattern Adapter?!
- Tu me dis que je fais mal, mais pas comment faire bien... Cela fait un peu donneur de leçons je trouve.
Bon, et après, il faudra m'expliquer en quoi ce n'est pas testable comme code... ayant justement des classes qui masquent tout leur contenu et également leur fonctionnement au reste du code, je trouve au contraire cela très facile à tester.
(De manière annexe, pour le coté "y'a parfois des projets avec trop de classes qui ont 3 lignes", je rejoins en fait ce billet de blog. Un autre billet est également dans le même ordre d'idée, billet qui tend à prouver qu'à trop découper un problèmes en trop petits éléments, on perd plus de temps à recoller les éléments entre eux qu'à résoudre le problème général lui-même; et ce n'est pas un pancake du fond des landes qui le dit...).
- Si on utilise le Conteneur, une méthode ".traduction" dans la classe Livre, méthode chargée de faire la traduction du Livre, et le code utilisateur doit donc itérer sur chaque élément du conteneur pour le traduire (donc, "on se retape la boucle for à chaque fois")
- Si on passe par la bibliothèque, celle-ci implémente une méthode "traduire()" qui se charge de traduire la bibliothèque entière (pas forcément Livre à Livre donc, je m'en fous de comment elle traduis)
Pour le Erlang, il va falloir que je prenne le temps de comprendre le fonctionnement... Pour le 1er code, si j'ai bien suivit, la bibliothèque est effectivement un "bête" conteneur, donc j'ai pas de problème avec ça, et ça me va.
En revanche, dans le 2nd code (si je le comprend bien, parce que je n'en suis vraiment pas sûr), Bibliothèque a une méthode qui itère sur chacun des objets qu'elle contient, et qui exécute la fonction de traduction pour chaque objet... Or, à mon sens, cela revient donc à traiter (depuis le code utilisateur qui appelle le "replace_all_book") le conteneur dans son ensemble, et là, je trouve cela mal venu, car une même classe peut être traitée "élément par élément", comme un Conteneur classique, mais aussi "dans son ensemble", comme un objet pur. Je trouve les deux peu compatibles, et je pense que ces deux notions devraient aller dans deux classes (ou équivalent) séparées, l'une étant le conteneur des données et l'autre étant l'objet représentant l'ensemble des données de façon indissociable.
En revanche, là, Oxman je ne te comprends pas pour plusieurs raisons:
- Adapter fait la transition entre deux classes, or un Conteneur n'est pas, à mon sens et comme exposé plus haut avec tout mon "bullshit sur les atomes", un objet/classe. Donc "Bibliothèque" n'est pas un Adapter, puisque ne "passe" pas une classe (ConteneurLivre) en une autre (Bibliothèque). Ou alors, tout est objet est un Adapter...
- Tu me dis que je fais le pattern Adapter mais qu'en fait je le fais pas comme il faut... Donc en fait, je ne fais pas ce pattern... Ou, dis autrement, t'es si sûr que ça, que je fais "juste" un pattern Adapter?!
- Tu me dis que je fais mal, mais pas comment faire bien... Cela fait un peu donneur de leçons je trouve.
Bon, et après, il faudra m'expliquer en quoi ce n'est pas testable comme code... ayant justement des classes qui masquent tout leur contenu et également leur fonctionnement au reste du code, je trouve au contraire cela très facile à tester.
(De manière annexe, pour le coté "y'a parfois des projets avec trop de classes qui ont 3 lignes", je rejoins en fait ce billet de blog. Un autre billet est également dans le même ordre d'idée, billet qui tend à prouver qu'à trop découper un problèmes en trop petits éléments, on perd plus de temps à recoller les éléments entre eux qu'à résoudre le problème général lui-même; et ce n'est pas un pancake du fond des landes qui le dit...).