[JS] Boucle for..in Array et ajout de methodes via prototype = conflit?!

[BAK]

Salut,

Je viens défendre mon point de vue, et désolé Xenos, j'ai 21 ans et je sui pas d'accord avec toi


Le principe d'un objet n'est pas de ne rien connaitre sur lui, mais d'offrir un certains nombre d'interactions et de configurations, à travers ses méthodes et attributs publiques. Tout ce qui ne sert pas de données d'entrées ou de sortie ne doit pas être exposé, il s'agit des rouages internes.
Dans le cas d'une bibliothèque, je lui demande de stocker mes livres et de pouvoir les retrouver plus tard. Les livres eux-mêmes ne font pas parti des mécanismes internes de la bibliothèque, ce sont des objets fournis par l'utilisateur de la bibliothèque, et dont la bibliothèque sert à manipuler plus simplement.

En revanche, savoir que les livres sont stockés dans un Array ou autre, cela ne nous intéresse pas. C'est un détail d'implémentation.
Faire un library.arrayBook.forEach(callback) n'est donc pas une bonne solution, puisque l'on expose arrayBook.
Dans ce cas, la bibliothèque qui utilise un Array (par héritage ou composition, les deux ont des avantages et inconvénients) devrait proposer sa propre méthode forEach.
On obtient alors library.forEach(callback). Rien ne nous dit qu'en interne un Array est utilisé, et la bibliothèque peut faire ses vérifications (par exemple lancer une exception si un livre est abîmé durant l'opération).

Je ne considère pas le fait de passer une callback comme un problème d'un point de vue POO. La notion de callback vient du monde de la programmation fonctionnelle, mais elle n'est pas incompatible avec la POO. On peut voir ça comme une demande de l'utilisateur à la bibliothèque: "effectue cette action sur tout les livres pour moi".
L'action elle-même est du code utilisateur et n'est pas connu par la bibliothèque. Mais cela ne gère pas la bibli: elle propose d'appliquer un certain type d'action sur ses livres (dans notre cas, une fonction (Book) -> void) sans se poser de questions.

Enfin, pour résoudre la spécialisation des bibliothèques (papier ou électronique), on a les interfaces (ou classe abstraites suivant les langages).
On aurait deux classes Library et Book, abstraites. Avec 2 spécialisation: d'un coté les classes PaperLibrary et PaperBook, de l'autre les classes ElectronicBook et ElectronicLibrary.
Si on veut changer de type de bibliothèque, ça pose pas de problème. Et si on utilise les 2 types de bouquins en même temps, oui, il peut y avoir des problèmes, mais c'est à la bibliothèque de gérer ça (soit en refusant le livre à coup d’exceptions et de code d'erreurs, soit en le convertissant).


PS: J'ai pas trouvé de formatage pour écrire du code inline sur le forum. Y'a un moyen de faire ça ?

[niahoo]

Si tu aimes tellement la pureté Xenos jette un coup d'oeil à Haskell.
Pour le code inline c'est [var]comme ça[/var]

[Xenos]

@BAK ok, le points de vue est bien exposé, et ça se défend (mais je ne suis pas convaincu... Ok, la "conviction" ne vaut pas tripette comme argument mais bon ^^).
Et les langages purement fonctionnels, ça a la classe :p

Et ok, je pensais (au vu des gens que je connais) que l'âge avait à voir avec certaines méthodes de programmation (les petits jeunes qui disent JAVAAAAA et vieux qui répondent COBOOOOL et les moyens qui ne connaissent qu'une lettre de l'alphabet avec des +), mais finalement, cela doit plutôt dépendre des gens (et des écoles?).

Pour moi, un objet est "atomique", mais apparemment, pas pour tout le monde :p Je ne sais pas trop qui a "raison"...

[srm]

En fait c'est relativement simple, tu es content de casser le modèle objet pour avoir un truc plus rapide que ceux qui font tout en objet propre.

Bah désolé tu inventes rien autant faire du procédural ça sera encore plus rapide.

Ceci-dit, on peut très bien faire de l'objet propre et avec des performances satisfaisantes pour notre besoin.

Et ton exemple ou tu traites les données/calculs bien plus vite que ceux qui ont pensé en objet classique est pas vraiment un exemple, puisque moi dans tous les travails ou j'ai été, j'étais capable de faire de l'objet propre plus rapide que leur code procédural.

[Xenos]

C'est un exemple, mais c'est pas forcément une vérité générale. Il illustre peut-être le problème de "sur-généraliser" les objets, ce qui les rends très peu performants dans des cas spécifiques (qui, je sais, pourraient être traités avec des héritages utilisant des hypothèses précises).

Pourquoi considérer les objets comme "atomiques" (indivisibles et dans lequel la question de récupérer un "composant" de l'objet est absurde) casserait-il le modèle objet lui-même? Je n'ai rien contre le fait même de récupérer un Livre depuis la Bibliothèque, mais j'ai du mal à considérer que l'objet Livre ainsi renvoyé est un objet issu de la Bibliothèque.

[Maks]

Moi mon avis de "petit jeune" (et tout le monde osef) c'est que vous vous prenez sacrément la tête pour un foreach

A dans 10 page lol

[niahoo]

ben c'est comme ça qu'on apprend...

---

et faut pas confondre indivisible car atomique et indivisible parce que l'objet de 20 000 lignes est tres fortement couplé à tout le reste de l'appli

[Xenos]

Je ne confonds pas (je pourrai dire aussi "ne pas confondre objet "atomique" et objet "petit", avec 4 lignes de code; j'ai d'ailleurs horreur de ce genre d'objets car cela me donne toujours l'impression que, si cela avait été des fichiers et dossier, la classe "dossier" aurait juste un jeu "fichier" de 3 lignes...).

[BAK]

Xenos, dans ce cas, que penses-tu des designs patterns ?
Parce que le design pattern Strategy par exemple, ça correspond à 100% à ta notion de classe "non atomique".
Et il y a bon nombre de design qui sont justement destinés à séparer certaines fonctionnalités de leur classe.

On peut s'en passer, mais c'est sacrément utile de temps en temps.

[srm]

Ne serait-ce que pour les tests unitaires c'est indispensable
Bah parce que l'objet Livre il peut faire partie de ta Bibliothèque mais il pourrait aussi faire partie de UtilisateurBibliothèque, ou aussi faire partie de Magasin et de tas d'autres choses aussi.