Discussion :

[Invité]

La composition dans les autres langages fonctionne de façon similaire à JS, ça s'appelle l'injection de dépendance. Concrètement en JS lorsque tu composes ton objet, tu lui injectes des fonctions tierces qui sont accessibles au sein du dit objet. De manière similaire tu peux passer des arguments aux constructeurs des classes que tu assignes à des variables pour y accéder à tout moment dans ton objet.

Tu dis que tu peux composer deux objets sans connaître le code de ces objets mais tu dois bien connaître le code de l'objet injecté sinon tu ne peux pas utiliser ces méthodes. De même, tu dois bien modifier le code de l'objet composé pour injecter le second objet.


Encore une fois je ne veux pas rentrer dans le débat JS bien ou pas, je l'utilise régulièrement dans le cadre du boulot et si ce n'est clairement pas mon langage préféré ça ne me dérange pas de l'utiliser en connaissant ses faiblesses pour ne pas me faire piéger. Je dis juste que la composition n'est pas du tout liée aux prototypes, c'est un pattern qui est utilisable, et très utilisé, par de nombreux langages.

[Invité]

Pourtant, c'est bien le Gang of Four, qui le dit. Ils sont ni plus ni moins que les créateurs de la POO de manière générale.

Le Gang of Four, c'est les design patterns, dans les années 90. La POO ça date de l'époque smalltalk, dans les années 70.

[blbird]

Tu dis que tu peux composer deux objets sans connaître le code de ces objets mais tu dois bien connaître le code de l'objet injecté sinon tu ne peux pas utiliser ces méthodes. De même, tu dois bien modifier le code de l'objet composé pour injecter le second objet.

En Prototype, justement non, aucun besoin de modifier les codes sources des objets en question.

Les langages basés sur la POO par prototype fonctionnent différemment de ceux basés sur la POO par héritage. Vouloir essayer de dire que c'est pareil n'aide pas vraiment à comprendre les différences.

Le Gang of Four, c'est les design patterns, dans les années 90. La POO ça date de l'époque smalltalk, dans les années 70.

C'est vrai, mais c'est eux qui ont généraliser les principes actuels d'utilisation de la POO. Et ils ont très bien comparés la POO en mode prototype de celle en mode héritage. Et ce n'est pas parce qu'il y a des interfaces ou un DP Composition que la POO par héritage est la même que la POO par prototype, loin de là.

A la base, c'est déjà totalement différent. Et la plupart des différences que certains estiment mauvaises sont principalement dû à ces différences de conception du langage.

[Invité]

En Prototype, justement non, aucun besoin de modifier les codes sources des objets en question.

Les langages basés sur la POO par prototype fonctionnent différemment de ceux basés sur la POO par héritage. Vouloir essayer de dire que c'est pareil n'aide pas vraiment à comprendre les différences.

Ok tu peux certes assigner dynamiquement n'importe quel objet à n'importe quel autre sans changer le code de l'objet mais c'est une très mauvaise pratique car niveau maintenabilité c'est l'horreur. D'ailleurs dans la vidéo que tu proposes, le mec explicite bien dans son code l'assignation de barker & co avec Objetc.assign() dans la définition de l'objet murderRobotDog. Tu n'es donc pas obligé de le faire certes, mais c'est vraiment pas recommandé car si par exemple tu assignes dynamiquement barker() à l'objet murderRobotDog, à l’échelle d'un projet il pourra bark() dans certains scripts et pas dans d'autres.

Du coup tu dois bien modifier le code de ton objet si tu veux faire ça proprement sinon quelqu'un qui passe derrière toi ne vas rien comprendre. Et c'est exactement pareil dans les autres langages, tu as 2-3 lignes de codes dans ta classe qui gère l'inclusion d'un objet tiers.

Je ne dis pas du tout que la POO par prototype c'est la même chose que la POO disons classique, mais que dans ce cas précis c'est très similaire et que ok JS te permet des libertés mais c'est franchement pas recommandé dès que ton projet prend un minimum d'ampleur.

[blbird]

Je ne dis pas du tout que la POO par prototype c'est la même chose que la POO disons classique, mais que dans ce cas précis c'est très similaire et que ok JS te permet des libertés mais c'est franchement pas recommandé dès que ton projet prend un minimum d'ampleur.

Et donc la seule réelle manière de faire "bien" les projets c'est de l'héritage type C# ou Java, parce que c'est ce que tu connais?

Non, ce n'est pas le "bordel", petit ou gros projet, ce sont des règles d'utilisation différentes, qui permettent entre autres de ne pas être bloqué par un héritage défini, fermé, qui va t'empêcher de l'utiliser correctement car ce n'est plus ce que tu as besoin.

Tout langage, si tu l'utilises mal (en particulier si tu l'utilises sans le connaitre), te fera aller dans le mur. Est-ce que le C++ c'est le mal parce que tu dois gérer la mémoire, qu'il permet l'héritage multiple et les pointeurs?

[kilroyFR]

Est-ce que le C++ c'est le mal parce que tu dois gérer la mémoire, qu'il permet l'héritage multiple et les pointeurs?

C# a ete inventé a une epoque ou les gens voulaient faire du C mais coder avec la facilité du VB; alors tout ce qui etait compliqué ou il fallait reflechir/etre rigoureux on l'a supprimé (malloc/free, pointer etc).
Tout a fait; ce sont les devpeurs les coupables pas le langage lui meme.
Moralité maintenant on se retrouve avec des devs C# qui se croient les rois du monde mais ne comprennent toujours pas comment fonctionne ce putain de garbage collector qui decide de desallouer au mauvais moment, fait des new a tour de bras sans se soucier de comment ca marche et des impacts.

[Invité]

Est-ce que le C++ c'est le mal parce que tu dois gérer la mémoire, qu'il permet l'héritage multiple et les pointeurs?

Bah d'après les développeurs de rust, oui. De plus, il y a de nombreuses recommandations autour du C++, pour justement éviter d'aller dans le mur (http://isocpp.github.io/CppCoreGuide...CoreGuidelines).

[blbird]

Bah d'après les développeurs de rust, oui. De plus, il y a de nombreuses recommandations autour du C++, pour justement éviter d'aller dans le mur (http://isocpp.github.io/CppCoreGuide...CoreGuidelines).

Ah tiens, certains développeurs d'un langage Y qui disent que d'autres langages c'est de la d..be? Oh mais quelle surprise dit-donc, on est en plein dans le sujet.

Je laisse les devs C++ répondre, ca pourrait être fun.

N'empêche, vraiment fatiguant cette guerre de chapelles.... Tout est bon pour discréditer d'autres langages, y compris la recherche Google "langage X pas bien".

C'est si difficile que ca de s'ouvrir un peu, se documenter, d'essayer de comprendre les avantages et inconvénients, les cas d'utilisation des différents langages?

[LSMetag]

Pourtant, c'est bien le Gang of Four, qui le dit. Ils sont ni plus ni moins que les créateurs de la POO de manière générale.

Encore une fois, cela n'à rien à voir. Avec JS, de base, tu peux composer n'importe quel objet avec n'importe quel objet. Sans connaître ou modifier le code d'aucun des 2. Je serais curieux de savoir comment tu ferais pour interfacer 2 classes C# (ou Java) sans avoir à toucher au code de ces 2 classes?

Je cite Wikipedia :


Comme le JS se base avant tout ce le principe de la POO par Protrotype, la plupart des développeurs qui estiment que c'est un mauvais langage n'ont souvent juste pas bien compris la différence, ni les avantages (et inconvénients) qui vont avec.

En .NET et probablement ailleurs, on utilise l'injection de dépendance et les interfaces pour effectuer cette composition. Pas besoin de modifier son code. Juste effectuer un mapping ou une configuration préalable. Au moins, on sait ce qu'on fait malgré tout.
Wikipedia comme source, j'ai connu mieux. Après tout j'y avais bien écrit une énorme connerie (volontairement) qui avait été corrigée au bout d'un an.

C'est une question de goûts. Moi j'aime être encadré, qu'il y ait des règles. Contrairement à un autre langage (surtout compilé), JS tu es tenu d'en connaître les spécificités et donc d'avoir de l'expérience. Il est dur de se débrouiller et d'apprendre sur la tas, comme on nous l'impose souvent, si le projet n'est pas au moins à 50% JS (ce qui n'est pas souvent le cas et dans le cas contraire tu accumules le retard sur ce projet avant de maîtriser).

A l'école on t'enseigne les règles de typage, d'algorithmie, de POO,... En 7 ans d'études en informatique (IUT + Licence Pro + 2 masters différents), j'ai dû faire 6h de Javascript en tout (cours + TP). Et juste du DOM et de l'événementiel. Javascript bouscule même nos concepts algorithmiques. Il faudrait au moins 10 fois plus d'heures de cours.
Les passionnés en revanche qui codent sur leur temps libre (ou depuis qu'ils ont 12 ans) ont souvent moins ce problème.

[Invité]

Ah tiens, certains développeurs d'un langage Y qui disent que d'autres langages c'est de la d..be? Oh mais quelle surprise dit-donc, on est en plein dans le sujet.
...
N'empêche, vraiment fatiguant cette guerre de chapelles....

Dans ce cas, tu ne devrais peut-être pas participer à une discussion sur les langages préférés...

[foetus]

La composition dans les autres langages fonctionne de façon similaire à JS, ça s'appelle l'injection de dépendance.

Justement non
La composition/ la notion d'interfaces JS correspond aux mixins ou pour simplifier à une chaine d'héritages simples (*) (parce que JS, Ruby, ... ne propose pas l'héritage multiple, mais l'encadre en permettant de coder des objets "en plusieurs parties")


blbird va encore nous dire que JS fonctionne comme les autres langages ... mais comme la chaîne de prototypes est très fastidieuse à construire/ gérer (pour gérer les propriétés prototype et constructor et faire en sorte que les méthodes instanceOf et "je-ne-sais-plus" fonctionnent) on simplifie avec une simple chaîne et ceci en utilisant tous les sucres syntaxiques de ES6 ou ES2015 (*)


* : parent -> mixin1 -> mixin2 -> ... -> mixinN -> object

[Invité]

Et donc la seule réelle manière de faire "bien" les projets c'est de l'héritage type C# ou Java, parce que c'est ce que tu connais?

Non, ce n'est pas le "bordel", petit ou gros projet, ce sont des règles d'utilisation différentes, qui permettent entre autres de ne pas être bloqué par un héritage défini, fermé, qui va t'empêcher de l'utiliser correctement car ce n'est plus ce que tu as besoin.

Tout langage, si tu l'utilises mal (en particulier si tu l'utilises sans le connaitre), te fera aller dans le mur. Est-ce que le C++ c'est le mal parce que tu dois gérer la mémoire, qu'il permet l'héritage multiple et les pointeurs?

En gros tu es un évangéliste JS c'est ça ? Parce que je suis en train de dire que c'est possible de faire les choses de manière à ce qu'elles soient maintenables en JS (cf. la vidéo que tu as toi même postée) mais que ça implique de pré-définir tes objets et tu me parles d'héritage. Je design 90% de mes projets par composition donc non je ne pense pas que l'héritage soit un très bon pattern dans beaucoup de cas, notamment quand tu n'as pas une hiérarchie claire entre les objets (souvent donc). Désolé mais quand ton projet va grossir et que tu vas avoir des scripts qui en appellent d'autres, devoir retracer chaque objet pour être sur que tu ne casses rien au lieu de simplement avoir à lire sa définition est infiniment plus long et pénible.

Et pour ta gouverne j'adore gérer la mémoire ! J'ignore pourquoi mais mettre des bits dans des cases ça me détend

Justement non
La composition/ la notion d'interfaces JS correspond aux mixins ou pour simplifier à une chaine d'héritages simples (*) (parce que JS, Ruby, ... ne propose pas l'héritage multiple, mais l'encadre en permettant de coder des objets "en plusieurs parties")


blbird va encore nous dire que JS fonctionne comme les autres langages ... mais comme la chaîne de prototypes est très fastidieuse à construire/ gérer (pour gérer les propriétés prototype et constructor et faire en sorte que les méthodes instanceOf et "je-ne-sais-plus" fonctionnent) on simplifie avec une simple chaîne et ceci en utilisant tous les sucres syntaxiques de ES6 ou ES2015 (*)


* : parent -> mixin1 -> mixin2 -> ... -> mixinN -> object

Mea culpa tu as raison, j'ai employé le mot dependency injection trop vite je n'ai pas pensé aux mixins. Cela dit c'est ce que je sous-entendais quand je disais que ça fonctionne de façon similaire : tu as du code externe à un objet et tu donnes à ton objet l’accès à ce code.

[blbird]

En .NET et probablement ailleurs, on utilise l'injection de dépendance et les interfaces pour effectuer cette composition. Pas besoin de modifier son code. Juste effectuer un mapping ou une configuration préalable. Au moins, on sait ce qu'on fait malgré tout.
Wikipedia comme source, j'ai connu mieux. Après tout j'y avais bien écrit une énorme connerie (volontairement) qui avait été corrigée au bout d'un an.

C'est une question de goûts. Moi j'aime être encadré, qu'il y ait des règles. Contrairement à un autre langage (surtout compilé), JS tu es tenu d'en connaître les spécificités et donc d'avoir de l'expérience. Il est dur de se débrouiller et d'apprendre sur la tas, comme on nous l'impose souvent, si le projet n'est pas au moins à 50% JS (ce qui n'est pas souvent le cas et dans le cas contraire tu accumules le retard sur ce projet avant de maîtriser).

A l'école on t'enseigne les règles de typage, d'algorithmie, de POO,... En 7 ans d'études en informatique (IUT + Licence Pro + 2 masters différents), j'ai dû faire 6h de Javascript en tout (cours + TP). Et juste du DOM et de l'événementiel. Javascript bouscule même nos concepts algorithmiques. Il faudrait au moins 10 fois plus d'heures de cours.
Les passionnés en revanche qui codent sur leur temps libre (ou depuis qu'ils ont 12 ans) ont souvent moins ce problème.

J'aurais vraiment tout eu ici. Même que dans Wikipédia les articles informatiques disent n'importe quoi. C'est fou ca, ils ont tord dans toutes les langes. Il y a un paquet d'imbéciles quand même, entre ceux qui ont écris et ceux qui ont lus sans piper mot que c'était faux, c'est fou. (je t'invite à chercher ailleurs, tu trouveras pleins de sites que tu juges sérieux, qui en parle avec les même conclusions)

Libre à toi de préférer la simplicité plus structurée à une plus grande liberté qui l'est forcément moins, mais ca ne veut pas dire que l'une ou l'autre est meilleur ou moins bien.

L'injection de dépendance est utile pour essayer de découpler au maximum les langages POO qui utilisent l'héritage simple. Mais encore une fois :

1. Ton ID elle se fera sur une classe ou une interface spécifique, et il faut l'avoir prévue dans la classe où tu veux faire ton ID : déjà, tu touches obligatoirement à une des 2 classes, et tu te limites à coupler à quelque chose de déjà connu (injection par constructeur, la plus utilisée)
2. Les ID sont faites pour découpler le plus possible car le trop fort couplage qu'induit l'héritage, on essaye de l'éviter dans des gros projets (voir même moyens)
3. En JS, pas besoin de ca. Tout est de base découplé, et tu peux (a)coupler tout objet avec tout autre objet(s), et même à la volée. C'est pas beau ca?

Merci d'avoir parler de l'injection de dépendances, cela permet de voir qu'en POO par héritage simple, on cherche à tout prix à découpler un maximum, car on a bien vu depuis le temps que c'était clairement pas l'idéal car trop rigide. Et le JS le fait naturellement, car il a été créé avec cette notion de prototype, qui permet de ne pas avoir ce genre de problèmes.

Le JS est basé sur un concept différent. Ce n'est pas pareil, et vouloir absolument que ce soit le cas mène à un mur d'incompréhension (même pour certains qui l'utilisent d'ailleurs).

En gros tu es un évangéliste JS c'est ça ?

Absolument pas non.

Et pour ta gouverne j'adore gérer la mémoire ! J'ignore pourquoi mais mettre des bits dans des cases ça me détend

J'adore, merci pour le fun.

[foetus]

tu te limites à coupler à quelque chose de déjà connu

C'est un concept : coder un objet avec une interface privée
Parce que jusqu'à preuve du contraire, le principe de l'objet c'est de proposer une interface "connue" pour être utilisée par d'autres objets.

Les ID sont faites pour découpler le plus possible car le trop fort couplage qu'induit l'héritage

Non pas du tout : Un objet A dépend d'un autre objet B pour faire 1 ou des traitements. Donc au lieu de faire de la composition (un attribut et non pas la notion d'interface), on préfère l'agrégation/ injection de dépendances pour pouvoir avoir la possibilité de changer cet objet B et ainsi pouvoir avoir plusieurs scénarios (tests, debug/ realease, mise à jour, ...)

en POO par héritage simple, on cherche à tout prix à découpler un maximum, car on a bien vu depuis le temps que c'était clairement pas l'idéal car trop rigide.

Ce qui me fait rigoler c'est que tout le monde (dont toi) crache sur l'héritage "c'est trop couplé"
Mais tu codes comment les mixins ? les traits ? les objets CRUD ? les interfaces ? avec de l'héritage plus ou moins maquillé

[blbird]

C'est un concept : coder un objet avec une interface privée
Parce que jusqu'à preuve du contraire, le principe de l'objet c'est de proposer une interface "connue" pour être utilisée par d'autres objets.

C'est effectivement le principe dans un langage OO par héritage simple. Ce n'est pas obligatoire dans un langage qui utilise de l'OO par prototype.

Non pas du tout : Un objet A dépend d'un autre objet B pour faire 1 ou des traitements. Donc au lieu de faire de la composition (un attribut et non pas la notion d'interface), on préfère l'agrégation/ injection de dépendances pour pouvoir avoir la possibilité de changer cet objet B et ainsi pouvoir avoir plusieurs scénarios (tests, debug/ realease, mise à jour, ...)

Oui et? Cela ne change rien au fait que ton injection se fait obligatoirement avec une classe implémentant une interface particulière. Tu ne peux pas faire de l'injection d'une classe qui n'implémente pas cette interface. Dans le cas d'une nouvelle classe à injecter, il te faut donc forcément modifier cette classe pour y arriver.
(Au passage, même la notion de composition entre un langage OO par héritage et un langage OO par prototype n'est pas la même)
En JS, il n'y a pas d'interface, ni de classe, on est en prototype, pas en héritage classique. Ce sont les noms des fonctions qui font office de définitions d'objets, d'où une plus grande liberté. Si tu as besoin de faire une DI avec tout objet qui contient la fonction toString(), tu pourras la faire avec n'importe quel objet qui contient cette signature de fonction, existant ou futur. Sachant qu'en plus, tu peux rajouter des fonctions à la volée, dynamiquement, sur tout objet.
C'est juste un niveau de liberté supplémentaire. Mais là on ne parle que d'une différence en particulier, il y en a d'autres.

Ce qui me fait rigoler c'est que tout le monde (dont toi) crache sur l'héritage "c'est trop couplé"
Mais tu codes comment les mixins ? les traits ? les objets CRUD ? les interfaces ? avec de l'héritage plus ou moins maquillé

Perso je ne "crache" sur rien du tout, j'explique des différences, que beaucoup trop de monde prend comme étant des "problèmes" ou des "erreurs". Ce sont juste des concepts de langage différents. J'ai énormément utiliser les DI et l'IOC pour savoir que ce sont des concepts extrêmement utiles, dont le seul but est de rendre modulaires et moins couplé tes objets entre eux.

Tu remarqueras aussi que je n'ai jamais dit qu'un langage était meilleur ou moins bon qu'un autre.

Allez, un peu de lecture d'un des architectes de JS assez connu (créateur de JSON, excusez du peu), sur les différences entre OO par héritage classique et OO par prototype : http://javascript.crockford.com/inheritance.html

J'aime bien le tableau qu'il y utilise :

[Invité]

Moi je reste PHP à fond. Car facile d'utilisation et peu d'installation. D'autant plus que j'ai installé Ubuntu et télécharger et installer les paquets LAMP et je trouve que c'est plus facile et efficace d'utiliser Linux en PHP que Windows avec Wamp qui ne se charge pas quand le port 80 est occupé.

[sekaijin]

Pour le moment j'utilise JS pour le front et java pour les services

J'ai considérablement réduit est langages. je n'ai plus de HTML ni de JSP ou autre truc du genre je n'ai que du Javascript
et pour le CSS je n'interviens que très rarement dessus (la charte de l'entreprise faite une fois pour toute)

pour le front c'est 100% JS et côté client je ne génère rien côté serveur. j'utilise un micro framework MVC MVVM.
pour l'affichage j'utilise un framework qui lui est associé qui gère les composants graphiques sour forme de description JSON.
du coup toutes mes applicatiosn pour l'entreprise ont toutes exactement le même comportement et le même design.
à noter que les frameworks gère eux même l'adéquation avec le profil du terminal.

pour le backoffice j'utilise OSGi et les micro-services un framework Rest et JPA. là encore c'est très industrielle pas de questions complexes sur la structure du code et des composants des pojo annotés pour la persistance, des pojo annotés pour les micros-services métier des pojo annotés pour les services rest. un bout de xml pour relier le tout. l'infrastructure développé en interne se charge de l'authentification des droits des gestion d'erreur.

le tout est packagé sous forme de simple jar. les projet découpé en sous projets. soit le module est autonome et contient le front dans les ressources et l'ensemble des java. soit il s'agit de métier transverse et il n'y a que des micro-services avec la persistance si nécessaire, Soit il s'agit que d'un module d'usage qui embarque les web service et le front.

dans tout les cas le simple déploiement du jar rends les micros-services disponible et s'il y a du front le menu du module est automatiquement ajouté à l'interface de l'utilisateur.

la mise au point a été relativement rapide et simple (1 semaine) depuis le processus de dev est devenu très industriel.
par contre et ce n'est pas le but il ne s'agit pas de fignoler le webdesign comme on peut en avoir besoin sur le net pour le marketing mais de faire des appli opérationnelle à usage interne. présenter des liste des grilles des arbres, agir sur le SI saisir des donnée optenir des renseignement et des stat.

A+JYT

[Aboubakar Ahamda]

Je suis encore étudiant et le web ne m'intéresse pas beaucoup, mais il me semble que Java (JEE) est difficile à apprendre (l'architecture) avec des trucs bizarre que parfois on sait même pas pour quoi on fait ça.(juste configure)
Avouons-le, c'est difficile de s'auto-former en JEE.

Le PHP je ne sais pas trop mais comme c'est simple et joli sans trop des configurations .

Et dire je suis développeur en java c'est synonyme de "je suis gourou d'un centaine de technos et framework" ,qui par des raisons mystères ,disparaîtront le lendemain.

J'utilise java dans le cadre académique (j'ai pas le choix) mais à vrai dire quand il s'agit du JEE ça me dégoûte.

Il va falloir que je me penche sur le PHP.

Mon langage préféré : C

[Vil'Coyote]

Pour le autre, j'utilise Adélia Web donc du langage Adélia ceci en plus des langages html, php, js, xml etc ....

[Spartacusply]

Je suis maintenant avec Angular 4 sur le front qui est vraiment bien pensé (merci Google et la communauté pour le coup !)

Concernant le back, node c'est tout simplement une tuerie niveau performance mais je reste aussi fidèle à PHP qui reste toujours facile d'accès tout en s'améliorant davantage avec le temps.