Discussion :

[blbird]

Je ne vois pas bien le rapport, on peut très bien faire de la composition en PHP ...
https://r.je/you-do-not-need-inheritance-oop.html
Bref, encore une preuve d'ignorance.

Arrête de traiter les autres d'ignorants quand tu affiches la tienne à longueur de réponses. Ce qui fait toute la différence, que tu n'as absolument pas comprise du tout, c'est que JS fait du prototypage dynamique directement dans le langage de base. Tout JS est basé là-dessus, comme le C# ou le Java sont basés eux sur le principes de classes et d'héritage. Et ton article va même clairement dans le sens de Javascript : il explique très bien que l'héritage est toujours plus mauvais que la composition. Ca tombe bien, JS est basé sur la composition dynamique : tu peux ajouter des comportements à la volée à tout instance de prototype (un objet en JS) quand tu en as envie. Bon courage pour faire pareil en POO dynamiquement, même avec les interface, sans toucher au code de tous les objets.

L'héritage, c'est quand tu définis les objets par rapport à ce qu'ils sont, la composition c'est définir les objets par rapport à ce qu'ils font. Et le JS excelle en composition, car c'est le fondement même du langage, bien plus que le design pattern Composition associé à un langage POO... Ca n'a juste rien à voir.

De la même manière que des mecs ont érigé des temples et des pyramides majestueux il y a 5000 ans avec des rondins.
On peut faire n'importe quoi avec n'importe quoi à condition d'y consacrer suffisamment d'efforts. On le fera juste moins vite et bien. Si tu aimes travailler avec des rondins tant mieux pour, perso je préfère utiliser une grue...

Ah ouais. Mais le mec qui sait conduire une grue, il comprend tout l'intérêt que ca a comparé aux rondins à la main. Par contre le mec qui est infoutu d'apprendre à conduire la grue, il passe son temps à la dénigrer car c'est trop compliqué à utiliser. Ca te rappelle quelqu'un?

C'est illisible parce que c'est illisible. Quand je lis du code, je ne devrais pas avoir à filtrer visuellement près de 3/4 d'éléments inutiles pour comprendre la logique.

C'est illisible parce que tu n'y comprends rien. De même que le japonais ou le russe te paraitrais illisible. Tu es juste incompétent et borné au possible, c'est tout.

Peut-on revenir au sujet plutôt que de subir ce troll?

Perso, VueJS est pour moi clairement plus sympa qu'Angular ou React. J'aime beaucoup la composition de composants, et la facilité d'apprentissage, la librairie minimaliste et la documentation extrêmement claire. Je suis content qu'il se développe.

Grâce à cet article, j'ai découvert GRAPHQL : j'adore, tout simplement. A découvrir absolument!

[Beginner.]

Par mots-clés je parle de la manière de déclarer les prototypes, fonctions dans des fonctions, variables dans des fonctions, etc.

Ah ben ça confirme que ce n'est pas facile de te suivre car pour moi "mot-clé" c'est la traduction de "keyword" et la liste des keywords est connu, un lien : https://developer.mozilla.org/en-US/...ammar#Keywords...

Dans l'exemple "var machin.prototype.maFonction = function() => { .. }" tu as 3 bons quarts du code qui ne servent à rien par rapport à "function maFonction() { };" ou même "maFonction() { };" dans les langages "normaux".

Lol... Cela ne sert pas à rien, ce n'est pas la même chose, le premier exemple c'est*** plus qu'une définition de fonction, on fait deux choses en une fois : on définit une fonction et on l'ajoute au prototype de "machin"...

Pour moi c'est lisible aujourd'hui mais c'est vrai pas à mes débuts car il faut savoir qu'en JS on peut ajouter une propriété à un objet via une affectation ce qui peut être déroutant quand on vient d'un autre langage qui ne permet pas cela mais voilà ça ce n'est pas de la faute du JS mais de la faute de ceux qui viennent d'un autre langage et s'attendent à ce que JS fonctionne pareil au lieu de comprendre qu'il a ses spécificités et qu'il faut faire l'effort de les apprendre faute de quoi une simple ligne comme celle que tu cites peut paraitre illisible et incompréhensible...

*** Enfin ce que je dis est valable si on enlève le mot-clé "var" que tu as mis devant et qui je suppose est une erreur de frappe, c'est ça ? Si ce n'est pas une erreur de frappe, j'aimerais bien que tu m'expliques où tu as vu ce genre de chose et qu'est-ce que cela est censé signifier...

[Pyramidev]

il explique très bien que l'héritage est toujours plus mauvais que la composition. Ca tombe bien, JS est basé sur la composition dynamique : tu peux ajouter des comportements à la volée à tout instance de prototype (un objet en JS) quand tu en as envie. Bon courage pour faire pareil en POO dynamiquement, même avec les interface, sans toucher au code de tous les objets.

L'héritage, c'est quand tu définis les objets par rapport à ce qu'ils sont, la composition c'est définir les objets par rapport à ce qu'ils font. Et le JS excelle en composition, car c'est le fondement même du langage, bien plus que le design pattern Composition associé à un langage POO... Ca n'a juste rien à voir.

Ajouter des comportements à la volée à une instance de prototype, ce n'est pas de la composition au sens orienté objet.
Tu sembles ne pas avoir compris les intérêts de la composition en POO.

Par exemple, admettons qu'on ait une classe X d'une bibliothèque externe, par exemple une classe pour loguer, ou bien un classe pour envoyer des courriels, ou bien une classe pour interagir avec une base de données.
Admettons qu'un programme contienne une classe Y qui encapsule X. Y est la seule classe du programme qui connaît X et n'offre pas toutes les fonctionnalités de X. Elle n'a que le strict nécessaire dont le programme a besoin.

Un jour, on se rend compte qu'il existe une bibliothèque externe Z qui semble meilleure que X sur plusieurs points. Peut-on remplacer X par Z dans le programme ?

Avec l'architecture ci-dessus, il n'y a besoin de n'analyser qu'une seule classe du programme (Y) pour savoir quelles fonctionnalités de X sont utilisées. Et si on décide de faire le changement, même si toutes les méthodes de Z ont des signatures complètement différentes de celles de X, cela ne pose pas de problème : il n'y a qu'une seule classe du programme à mettre à jour : Y.

Cette flexibilité est possible, car Y n'est pas une extension de X. Y a ses propres méthodes, avec leurs propres signatures. En outre, Y a volontairement moins de fonctionnalités que X.

Pour qu'un gros programme soit bien structuré et maintenable, il faut forcément beaucoup d'encapsulation, un peu partout.

L'héritage, lui, a d'autres buts. Il sert surtout à faire du polymorphisme.

Quand on dit qu'il faut généralement préférer la composition à l'héritage, c'est surtout parce que les débutants ont tendance à ne pas encapsuler. Dans mon exemple, un développeur mauvais en POO aurait fait une classe Y qui dérive de X pour y ajouter les méthodes qui l'intéressent car, à court terme, c'est plus rapide d'étendre à l'arrache les fonctionnalités d'une classe existante que de faire de l'encapsulation.

[Sodium]

C'est illisible parce que tu n'y comprends rien. De même que le japonais ou le russe te paraitrais illisible. Tu es juste incompétent et borné au possible, c'est tout.

Bref, ça gueule, ça insulte ... et personne n'a toujours pas été foutu de me trouver un exemple de beau code en JavaScript

Je n'aurai peut-être convaincu personne mais j'aurai au moins bien rigolé devant votre mauvaise foi affligeante, ainsi que l'incompétence de nombreux intervenants qui essayent de donner des leçons en mélangeant des concepts basiques de programmations

...

Tu expliques limpidement ce qu'essayait de démontrer l'auteur du blog cité plus haut que j'avais lu un peu en diagonale car l'auteur a tendance à être extrémiste en hurlant "telle pratique c'est le MAL et il ne faut JAMAIS le faire !"

[blbird]

Ajouter des comportements à la volée à une instance de prototype, ce n'est pas de la composition au sens orienté objet.
Tu sembles ne pas avoir compris les intérêts de la composition en POO.

Je parle de composition au sens plus vaste que celui de la simple POO. En JS, les capacités de composition sont natives ET dynamiques, via Object.Assign. Tu peux mixer les objets comme tu l'entends. C'est bien de la composition en Javascript, qui permet de faire bien plus de choses que la POO classique, en particulier de l'héritage multiple et mimer la POO (classes, héritage, interface) sans aucune difficulté : l'inverse n'est pas vrai.

https://www.richardkotze.com/coding/composition-in-javascript

Quand on dit qu'il faut généralement préférer la composition à l'héritage, c'est surtout parce que les débutants ont tendance à ne pas encapsuler. Dans mon exemple, un développeur mauvais en POO aurait fait une classe Y qui dérive de X pour y ajouter les méthodes qui l'intéressent car, à court terme, c'est plus rapide d'étendre à l'arrache les fonctionnalités d'une classe existante que de faire de l'encapsulation.

C'est une des choses qui m'a le plus frustré en POO : la possibilité de rendre privé, c'est-à-dire non modifiable, du code. Comme si un seul code pouvait se targuer d'être éternel. Combien de fois je me suis retrouvé devant des classes SEALED ou PRIVATE. Il n'y a absolument pas ce soucis en JS, tout est modifiable et même dynamiquement, encore une fois.

Au passage, l'encapsulation ne concerne en POO que les propriétés d'une classe. C'est un abus de langage de parler d'encapsulation de classe dans une autre, même si je comprend l'idée.

[Sodium]

https://www.richardkotze.com/coding/...-in-javascript

Bel exemple de code crade et illisible merci.

C'est une des choses qui m'a le plus frustré en POO : la possibilité de rendre privé, c'est-à-dire non modifiable, du code. Comme si un seul code pouvait se targuer d'être éternel. Combien de fois je me suis retrouvé devant des classes SEALED ou PRIVATE. Il n'y a absolument pas ce
soucis en JS, tout est modifiable et même dynamiquement, encore une fois.

Quand une variable ou une méthode est privée c'est pour une bonne raison : l'auteur du code ne veut pas que le fonctionnement de son code puisse être compromis parce que des données ont été modifiées en dehors du cadre prévu. Si une variable privée devient publique, ça veut dire qu'il faut en permanence la tester pour vérifier qu'elle a bien les valeurs attendues, c'est donc plus de boulot, du code moins lisible et plus de bugs potentiels. Ce n'est pas un soucis, c'est du bon sens de base... Bref, on en est encore à discuter de notions élémentaires de programmation que vous n'avez jamais acquises et qui vous rendent nuisibles pour les professionnels avec qui vous travaillez

Un autre tare des débutants en programmation est de déclarer toutes les variables en privées puis ajouter des getters et setters partout, alors que la plupart d'entre elles ne sont justement pas vouées à être lues ou modifiées en dehors de la classe.

[Marco46]

Pour la centième fois cet argument n'a aucune pertinence. On s'en fout de en quoi le code est transformé au final, ce qui importe au programmeur c'est le langage dans lequel il code. Après ça peut bien être transformé en JavaScript, en ActionScript, en C ou en ook je n'en ai absolument rien à foutre, c'est le job du transcompilateur, pas le miens, et personne (à moins d'être masochiste) n'ira jamais lire le code final en JavaScript.

Ça a de la pertinence dès lors qu'on prend la peine de regarder sous le capot pour comprendre ce qui se passe. TypeScript target par défaut ES3 c'est à dire une version de JavaScript qui a presque 20 ans. Si tu target la dernière version de JavaScript dispo dans le compilo TS tu verras qu'il y a très peu de modifications à l'arrivée.

Tu dois faire parti de ceux qui pensent que les classes, les modules ou les lambdas c'est un apport de TypeScript j'imagine ?

Euh je n'ai commencé à utiliser le typage statique qu'il y a 2-3 ans...

C'est pas beaucoup tu faisais quoi avant ? On t'a forcé à écrire de l'ES5 pendant 7 ans et du coup tu l'as mauvaise ?

L'absence de typage statique n'est qu'un problème parmi d'autres.

C'est le seul apport de TypeScript par rapport à JavaScript. C'est pour ça que ça s'appelle Type-Script.

[Sodium]

TypeScript target par défaut ES3 c'est à dire une version de JavaScript qui a presque 20 ans.

Pas trop le choix puisqu'il faut bien que le code soit lisible par tous les navigateurs.

Tu dois faire parti de ceux qui pensent que les classes, les modules ou les lambdas c'est un apport de TypeScript j'imagine ?

De un j'utilise ES2015 chaque fois que je fais du JavaScript, évidemment transformé après via webpack.
De deux habon, JavaScript a du typage statique, du typage des valeurs de retour, de l'injection de dépendances, les interfaces, la notion de variables privées maintenant ? Des déclarations de propriétés en dehors des fonctions d'une classe ? Whaou il faut absolument que tu me montres ça !
Par ailleurs vous vous contredisez à nouveau : JavaScript c'est super, les classes etc ça ne sert à rien ... maiiiis JavaScript c'est super parce que maintenant aussi faire des classes ?

C'est pas beaucoup tu faisais quoi avant ? On t'a forcé à écrire de l'ES5 pendant 7 ans et du coup tu l'as mauvaise ?

Principalement du PHP old school et pas mal de JS à base de prototypage.

C'est le seul apport de TypeScript par rapport à JavaScript. C'est pour ça que ça s'appelle Type-Script.

Eh bien c'est déjà un apport majeur. Ensuite la syntaxe de TypeScript ne ressemble absolument pas à du JavaScript et est immédiatement compréhensible par des programmeurs ayant fait du Java ou autre langage similaire, des langages normaux où l'on ne passe pas son temps à déclarer des fonctions dans des fonctions.
Si tu balances ce genre d'inepties, c'est probablement que tu ne t'es jamais penché sérieusement dessus.

[Beginner.]

Lol, je me demande qui sont ceux qui distribuent des "pouces rouges"...

Par exemple je me demande qui sont les deux membres qui m'ont mis un pouce rouge au message #42 ?

Y a-t-il une "bonne" raison ? Si oui j'aimerais bien savoir laquelle, ce serait plus productif de donner une explication... D'ailleurs dans ce message je réponds à Sodium qui lui non plus n'a donné aucune explication...

Ou bien dois-je comprendre qu'il n'y a aucune raison "valable" ? Que c'est fait bêtement juste pour soutenir un camp d'une manière aveugle sans chercher à comprendre ?

C'est marrant quand même...

[Beginner.]

EDIT : ah ça y est, grillé Sodium, lol... Cela ne m'étonne pas de ta part, tu fais vraiment pitié, un vrai gamin...

EDIT : Merci pour tes pouces rouges, c'est la seule réponse que tu puisses apportées par rapport au fait que tu racontais n'importe quoi, ce n'est pas facile d'admettre qu'on étais à coté de la plaque, allez je ne t'en veux pas je sais que ce n'est pas facile d'admettre, tu n'es qu'un gamin après tout, il faut bien que tu fasses mu-muse...

[Sodium]

Ah, il me semblait bien que je connaissais ton pseudo de quelque part. Grand prix international de l'éloquence 2018 non ?

[Beginner.]

Tu as prouvé que tu n'avais pas d'argument et quand c'est le cas tu n'as pas l’honnêteté de l'admettre et tu mets alors des pouces rouges... Quelque part tu fais pitié...
Bref ça veut bien dire que cela ne sert à rien de discuter avec toi...

Alors bonne continuation...

[Invité]

Lol, je me demande qui sont ceux qui distribuent des "pouces rouges"...

Par exemple je me demande qui sont les deux membres qui m'ont mis un pouce rouge au message #42 ?

Y a-t-il une "bonne" raison ? Si oui j'aimerais bien savoir laquelle, ce serait plus productif de donner une explication... D'ailleurs dans ce message je réponds à Sodium qui lui non plus n'a donné aucune explication...

Ou bien dois-je comprendre qu'il n'y a aucune raison "valable" ? Que c'est fait bêtement juste pour soutenir un camp d'une manière aveugle sans chercher à comprendre ?

C'est marrant quand même...

Peut-être parce qu'ils pensent que c'est "inutile, faux, pas d'accord..."

Ah ben ça confirme que ce n'est pas facile de te suivre car pour moi "mot-clé" c'est la traduction de "keyword" et la liste des keywords est connu, un lien : https://developer.mozilla.org/en-US/...ammar#Keywords...

Inutile.

Lol... Cela ne sert pas à rien, ce n'est pas la même chose, le premier exemple c'est*** plus qu'une définition de fonction, on fait deux choses en une fois : on définit une fonction et on l'ajoute au prototype de "machin"...

Pas d'accord. Dans les langages "normaux", tu mets juste la déclaration dans ou en dehors de la classe selon ce que tu veux et donc oui il y a bien "3 bons quarts du code qui ne servent à rien" en comparaison.

car il faut savoir qu'en JS on peut ajouter une propriété à un objet via une affectation

Inutile. Vu que c'est l'exemple de ton interlocuteur, j'imagine qu'il le sait très bien.

mais voilà ça ce n'est pas de la faute du JS mais de la faute de ceux qui viennent d'un autre langage

Pas d'accord. C'est un choix de conception et les concepteurs savaient que ce serait déroutant pour certain. Et je ne vois pas ce que la notion de "faute" vient faire la.

Du coup, je t'ai mis un 3e pouce rouge, inutile de me remercier.

[Marco46]

Pas trop le choix puisqu'il faut bien que le code soit lisible par tous les navigateurs.

Non mais ça c'est pour le run, il est évident que la version JavaScript de 1999 est obsolète. En 2018 on parle de ES2018. Tu es d'une mauvaise foi affligeante.

De un j'utilise ES2015 chaque fois que je fais du JavaScript, évidemment transformé après via webpack.

Je croyais que tu faisais du TypeScript ?

Sinon tu es à la bourre de 3 versions.

De deux habon, JavaScript a du typage statique, du typage des valeurs de retour, de l'injection de dépendances, les interfaces, la notion de variables privées maintenant ? Des déclarations de propriétés en dehors des fonctions d'une classe ? Whaou il faut absolument que tu me montres ça !

- typage statique : non.
- typage de valeurs de retour : on vient de répondre non.
- injection de dépendances : oui évidemment, c'est un mot compliqué pour dire "passer un paramètre à une fonction". A moins que tu ne fasses pas la différence entre le système de DI de Angular et TypeScript ? La DI se gère merveilleusement bien en natif sans aucun framework ou lib avec le destructuring et les lambdas.
- interfaces : non c'est vrai que c'est bizarre d'avoir ajouté les classes sans les interfaces. La meilleure chose à faire aurait été de ne pas ajouter les classes au JavaScript.
- variables privées : tu as les closures pour gérer ça mais apparemment ça arrive pour les classes.
- déclarations de propriétés en dehors des fonctions d'une classe : ça arrive. C'est en dehors du constructeur. On ne peut pas déclarer de propriété en dehors du constructeur.
- Whaou il faut absolument que tu me montres ça ! : il faut surtout que tu te formes au langage que tu utilises tous les jours !

Par ailleurs vous vous contredisez à nouveau : JavaScript c'est super, les classes etc ça ne sert à rien ... maiiiis JavaScript c'est super parce que maintenant aussi faire des classes ?

Pas du tout, je te fais simplement la remarque que tu utilises des choses sans savoir d'où elles viennent.

Principalement du PHP old school

Je comprends mieux. Tu as baigné dans un environnement cradingue depuis des années et tu découvres la sécurité du typage statique.

Eh bien c'est déjà un apport majeur.

Je ne le nie pas. C'est un gros plus pour décrire les modèles.

Ensuite la syntaxe de TypeScript ne ressemble absolument pas à du JavaScript

Je t'invite à faire l'exercice de target une version récente de JS. Tu vas simplement obtenir du boilerplate en plus pour gérer les types et les quelques features ajoutées par TypeScript. Tout le reste sera strictement identique. C'est justement parce que TypeScript est un superset de JS qu'il est agréable à utiliser, c'est très facile à intégrer doucement sans grand big bang.

et est immédiatement compréhensible par des programmeurs ayant fait du Java ou autre langage similaire,

Ça c'est un gros problème parce que beaucoup de ces programmeurs essaient de faire du Java avec TypeScript sans apprendre JavaScript et ça donne Angular.

des langages normaux où l'on ne passe pas son temps à déclarer des fonctions dans des fonctions.

Ça c'est un autre problème, c'est que tu n'as as encore regardé du côté de la programmation fonctionnelle qui est à la mode ces dernières années et qui est particulièrement bien adaptée aux problématiques du web, aussi bien front que back. La POO n'est pas la programmation normale, c'est un paradigme de programmation parmi d'autres.

Si tu balances ce genre d'inepties, c'est probablement que tu ne t'es jamais penché sérieusement dessus.

Tu as besoin d'une douche bien froide et de prendre un peu de recul.

[Beginner.]

Euh c'est bizarre que ce soit SimonDecoline qui réponde tout à coup survenu de je ne sais où mais en tous cas pas de la section JavaScript... C'est bizarre, tu es un pote de Sodium ou peut-être tu es un deuxième pseudo de Sodium ?

Peut-être parce qu'ils pensent que c'est "inutile, faux, pas d'accord..."

Ou peut-être que ce sont des gamins partis prit qui mettent des pouces rouges car ils ne savent pas être constructifs...

Inutile.

Inutile de montrer qu'il ne sait même pas ce qu'est un mot-clé, c'est ça ? Eh bien si c'est utile car cela explique pourquoi on a du mal à le suivre... Après toi c'est différent, tu n'es sans doute pas objectif puisque soit tu es Sodium soit tu es un de ses potes soit tu fais parti de son fan club soit... Je crois qu'on a compris...

Pas d'accord. Dans les langages "normaux", tu mets juste la déclaration dans ou en dehors de la classe selon ce que tu veux et donc oui il y a bien "3 bons quarts du code qui ne servent à rien" en comparaison.

Lol... Non mais depuis quand c'est toi ou ton pote qui juge qu'un langage est normal ou pas ?

Les prototypes c'est vrai que cela fait parti des spécificités de JS mais je vois pas en quoi cela le rendrait anormal, chaque langage a ses spécificités...

Après si on comprends qu'il voulait parler d'une méthode (fonction membre d'une classe) eh bien ils sont plusieurs à avoir rappeler que JS a évolué et si ton problème c'est juste ça eh bien il y a les classe maintenant et tu peux déclarer une fonction membre de la même manière, même plus besoin d'utiliser le mot-clé "function"...

Alors sa comparaison et ton soutient montrent qu’apparemment vous n'étiez pas au courant et c'est nous qu'on traite d'ignorant... Et si vous étiez au courant alors c'est que vous êtes de mauvaise foi...

Quoi qu'il en soit je ne vois pas en quoi l'usage des prototypes rendrait le code illisible comme le prétend Sodium...

Inutile. Vu que c'est l'exemple de ton interlocuteur, j'imagine qu'il le sait très bien.

Eh bien peut-être que toi tu le sais mais pas moi car ce n'est pas mon pote et je ne lis pas dans les pensées...

En plus ce qu'il a écrit c'est : "var machin.prototype.maFonction = function() => { .. }" avec le mot-clé "var" ce qui pour moi n'a aucun sens donc je ne crois pas que ce que j'ai rappelé soit si inutile que ça et tu as beau imaginer qu'il le sait très bien, cela ne change rien, nous ce qu'on voit c'est ce qu'il écrit et toi si tu veux imaginez des choses c'est ton problème...

Bref, à toi aussi bonne continuation, cela ne m’intéresse pas de polémiquer avec Sodium ou son fan club...
Pas la peine d’envoyer encore une autre personne à la place de Sodium...

[Invité]

Euh c'est bizarre que ce soit SimonDecoline qui réponde tout à coup survenu de je ne sais où mais en tous cas pas de la section JavaScript...

Je ne sais pas si tu as remarqué mais ce fil est sur la page d'accueil de dvp...
Et puisque tu veux tant savoir, tes messages de fan boy parano étaient tellement drôles que je n'ai pas pu résister d'y répondre.

[melka one]

on peut limité le mot prototype un prototype est un objet il suffit d'utiliser un objet {} avec la syntaxe new on utilisera le mot une seul fois et avec object.create() il est inutile et le tour est joué par contre se sera moins lisible et la il y a conflit d’intérêt, contradiction.

il ne ne faut pas oublier que prototype permet aussi la modification d'un objet a la volé.

[sancelot]

Angular utilise une approche model-view qui lui permet de mettre à jour uniquement ce qui est nécessaire.

Qu'est ce qui te permet d'affirmer cela ?
techniquement parlant c'est tout a fait faux, notamment a cause du databinding, dans certaines applications pour palier au probleme on passe a reactjs.

[Sodium]

Je suis tombé là-dessus par hasard. Ce n'est (probablement) plus d'actualité mais ça m'a bien fait rire tout de même

https://www.destroyallsoftware.com/talks/wat