Classe vs Objet
Le mot classe/objet est toujours un débat compliqué en javascript.
Personnellement, dans ce cas je préfère parler de classe car, même si bien sûr ce n'est pas une classe comme on l'entend dans la plupart des langages objets, ce mécanisme est censé "simuler" une déclaration de classe pour le langage prototypé qu'est javascript. De plus parler d'objet, pour moi dans ce cas, prête à confusion car c'est le résultat de l'"instanciation" avec new qui donnera l'"objet" comme on l'entend en programmation orientée objet classique. D'un point de vue pédagogique et clarté, je pense donc qu'il est plus intéressant de parler de classe qui n'est finalement qu'un mot qui sert à représenter un comportement plutôt que d'objet qui sert à représenter un mécanisme sous-jacent.
Cependant, je tiens à redonner certainement la meilleure et plus concise définition d'un prototype qu'il m'ait été donné de lire, qui a été écrite par quelqu'un que tu connais bien Sylvain et qui je pense explique ton point de vue:
Le concept de prototype en JS est très simple: tout est objet, tout objet a un prototype, tout objet peut être le prototype d'un autre objet. Les objets héritent des propriétés de leur prototype, et peuvent les surcharger. Il n'y a donc qu'un seul concept, l'objet prototypé, contrairement à la POOC qui distingue classes et instances. L'héritage devient lui-aussi plus simple : j'ai deux objets A et B, je veux que B hérite de A, donc j'assigne A comme prototype de B. C'est tout !
Juste pour revenir sur l'aspect ES5: je ne pense pas que l'on puisse plus parler de classe en ES6 qu'en ES5 car, pour moi, le fonctionnement reste le même (à un micro chouilla prêt disons) malgré le mot clé
class qui n'est qu'un bon gros sucre syntaxique. Je me permets de donner le
lien vers le sujet de forum (d'où j'ai extrait la précédente citation notamment) et dont l'article en relation donne un point de vue très intéressant sur l'évolution de l'orienté objet en javascript.
Fonctionnel
Après sur l'aspect "fonctionnel" de ce code, je fais partie de l'ancienne école encore (pour combien de temps!) qui a tendance à développer son code serveur comme si le javascript côté client n'existait pas (ça m'aide pour le bookmarquing et à rationaliser ma façon de coder le javascript côté client), puis je rajoute ma couche de javascript côté client pour rendre le tout plus dynamique (je ne sais pas si ça peut aider à comprendre ce que je viens de dire mais voici un
lien vers la documentation (en anglais) pour voir comment j'ai traduit ça dans un fonctionnement ajax par exemple dans mon framework node.js). Ce qui fait que j'ai un peu de mal à resituer ce code dans cette façon de coder.
En gros, pour résumé rapidement mon point de vue sur le sujet:
on peut tout à fait envisager de partager le code de l'objet Panier côté client et serveur pour unifier les règles de gestion.
Oui, mais il y a beaucoup de choses à faire pour y arriver et donc je pense que l'intérêt pédagogique est principalement dans le code lui-même et non dans la fonctionnalité.
Après, je ne dis pas, bien sûr, que ce que je dis est la vérité, ce n'est que mon point de vue à la lecture de cet article et sur ce que je m'attendais à y trouver ou à ce que j'aurais aimé trouver si j'avais été un plus jeune développeur javascript.
Et tout ça n'enlève rien à la qualité globale de l'article (et de sa relecture donc)!
1 |
0 |