Discussion :

[yahiko]

La POO est utile. Pour preuve elle est utilisée.

Plus sérieusement, je pense qu'il n'y a pas de profonds désaccords.

L'héritage pour ne citer que cet exemple doit être utilisé avec parcimonie et de façon réfléchie pour les problèmes soulevés par Tarh, et il y en a d'autres. En effet, souvent les Interfaces (et encore plus à la sauce TypeScript ^^) sont préférables car limitant les effets de bord et le couplage parent/enfant. Une hiérarchie de classes avec beaucoup de niveaux peut donner un gros mal de crâne à celui qui doit debuguer

Après, il ne faut pas jeter le bébé avec l'eau du bain. Utilisée de façon interne à un projet/framework, l'héritage est un outil intéressant pour la réutilisation de code.

Maintenant, d'un point de vue utilisateur externe d'un framework, c'est rarement la meilleure solution que de dériver ses propres classes de celles du framework en question. La composition fonctionne tout aussi bien par exemple et limite le couplage.

[sekaijin]

Le petit débat sur l'héritage est intéressant mais il oublie un petit point.

Je suis d'accord qu'en java l'héritage mal utilisé conduit à des situation gênante pour ne pas dire plus.
et si l'emploie d'interface implémentation apporte une souplesse. je ne suis pas du tout d'accord pour généraliser cela.

il faut se rappeler un peu ce qui est de la théorie des langages et ce qui est de leur implémentations.
Si on repart de la base la notion d'interface et d'implémentation n'a aucune raison d'être. en effet un langage à objet est suffisent. Mais implémenter des langages comme ceux de la théorie pure est complexe lourd et coûteux. Donc tous les langage à objet opérationnel ont donc tous fais des choix s'écartant de la théorie.

Le plus important de ces choix est l'abandon de l'héritage multiple.
Ainsi un "ours" qui hérite de "mammifère" et de "printable" se voit affublé des caractéristiques "fonctionnelles" (UML) comme le dit @Tarh_ mais aussi d'un héritage purement technique.
le fait de n'avoir qu'un héritage simple à mené les chercheur sur les langages à élaboré des théorie sur les langages issue d'essais pratiques qui ont introduit les interfaces et implémentations.

On s'achemine aujourd'hui vers quelque chose d'intermédiaire.
Ainsi en Java est-il possible dans un interface d'avoir une implémentation par défaut. on s'approche de nouveau d'un héritage multiple.

En javascript c'est un peut particulier car la souplesse du langage permets des choses que les langages à objet à base de classes n'ont pas l'habitude. il est relativement simple de faire de l'héritage multiple ou tout du moins des mixins.

A partir du moment où on a un héritage multiple ou quelque chose de très proche les problèmes liés à l'héritage simple sont-il encore d'actualité ?

A+JYT

[Paleo]

Vous faites l'erreur de partir de la technique pour ensuite y chercher du sens. Essayez le chemin inverse.

"Si l'on repart de la base […] un langage à objets est suffisant"… Quelle base ? Un langage procédural aussi est suffisant. S'il s'agit de la théorie des langages à objets, celle qui donnerait le Nord aux langages, eh bien, je n'ai jamais rien lu dessus, et vous ?

À mon avis, qui n'est certes pas orthodoxe, l'héritage est un mécanisme technique de délégation automatique dont le sens fonctionnel est batard. Il n'existe aucun mot usuel pour traduire simplement ce que ça veut dire. Le mot "héritage" est à tout le moins inexact : dans la vie réelle, lorsqu'un enfant hérite d'un trait de caractère du parent, il s'agit de deux personnes distinctes (des instances) et non pas du moule qui les a créé (les classes). Et ensuite, il s'agit de reprendre telle ou telle chose du parent et non pas de tout reprendre puis d'ajouter quelque chose d'un peu spécialisé. On ne peut pas dire, dans la vie réelle, qu'un enfant est le parent. Cette position fonctionnellement ambigüe a induit des approximations dans le vocabulaire : la spécialisation (UML), l'héritage (POO), et le mot-clé extends (langages) désignent la même chose technique !

Le mécanisme des interfaces et des implémentations est au contraire quelque chose de naturel. Une interface est un contrat. On peut se la représenter comme une casquette. Un individu (un objet) est fait de chair et d'os (il a une existence propre en RAM), et il peut avoir simultanément la casquette de plombier, celle de mécanicien et pourquoi pas celle de manager. Dire qu'un individu a telle casquette signifie qu'il a toutes les compétences que l'on a convenu d'associer à cette casquette. Là où l'héritage de classes introduit un couplage fort entre la factorisation du code et la définition des contrats, le mécanisme des interfaces ne s'occupe que de la définition des contrats et laisse le développeur libre de factoriser son code comme il l'entend. Car, contrairement aux objets, une interface n'a pas d'existence réelle, elle n'est qu'une définition.

Cela permet les choix de design du langage TypeScript. Les interfaces en TypeScript n'ont pas d'existence à l'exécution. Elles servent à définir le typage, lequel est contrôlé en statique, c'est-à-dire au niveau de la compilation seulement. En cela, elles sont cousines des annotations de typage ajoutées en commentaires et que les bons IDE savent interpréter.

[SylvainPV]

Je continue de penser que ce débat pro/anti héritage ne présente aucun intérêt. Qu'on l'utilise à tout va ou qu'on s'en prive complètement, cela revient à appauvrir l'expressivité du langage dans les deux cas.

[Paleo]

En même temps, personne n'a soutenu qu'il faudrait s'en priver complètement. UML suggère une bonne utilisation de ce mécanisme.

[sekaijin]

Ou là on se calme
rien d'orthodoxe juste un peu d'histoire

lorsque les première notions de langage à objet sont apparue de façon purement théorique on a modélisé les choses et on est arrivé rapidement à la notion d'objet et d'héritage.
cet héritage étant naturellement multiple.
En étudiant les capacités de ses langages les notions d'interfaces et d'implémentation n'on alors pas vues le jour car l'héritage (multiple) permettait de répondre à tous les besoins.

Lorsqu'il a fallut passer de la théorie à la pratique les choses ce sont compliquées.
en fait on est partie d'idées nouvelles introduite dans des langages réel pour bâtir une théorie cohérente
et ces avancées théoriques ont été réintroduites dans les langages déjà existants.

En même on a implémenté avec des langages formel de nouveaux langages qui eux étaient construits en implémentant que ce que prévoyait la (les) théorie(s) là encore il n'y a jamais eu besoin d'ajouter des interfaces ou autres friends. Par contre on c'est rapidement aperçu que produire un analyseur sémantique (pour la compilation ou l’interprétation)
était beaucoup plus compliqué lorsqu'on introduisait l'héritage multiple que celui-ci soit fait à base de classe de prototype ou directement au niveau objet. de plus même lorsque on parvient à avoir un analyseur suffisent la programmation reste difficile à maîtriser.
C'est pour ces raisons très pragmatiques qu'on c'est alors intéressée à l'héritage simple. dès les première implémentation avant même de théoriser le sujet on a introduit des élément complémentaire pour résoudre des problèmes bloquant. Comme la notion de friend en C++

là encore on a bâtie des théories sur la POO à héritage simple et c'est alors que la notion d'interface/implémentation à été introduite.

depuis sont apparu bien des choses dont l'implémentation par défaut d'une interface qui du coup agit comme pour l'héritage. ou encore les mixins tout cela tends vers un héritage multiple.

Je pense donc que si l'assertion concernant l'héritage levée dans le cadre de l'héritage simple est légitime. il est en revanche nécessaire de se poser la question lorsque l'héritage n'est plus aussi simple.
Je ne dis pas que cette assertion est caduque. je dis qu'il ne faut pas la considérer comme vrai mais réévaluer les fait qui lui ont donné naissance.

si elle est toujours vrai "roule ma poule" mais si elle ne l'est plus il faut agir en conséquence.

A+JYT

[yahiko]

Hmm... Je sens qu'on s'écarte du sujet, mais peu importe

Pour reformuler l'explication sur l'héritage multiple, le problème qu'on rencontre notamment en C++ vient principalement du problème dit du losange et de l’ambiguïté qui peut survenir dans le choix de la méthode dans une classe héritant de deux parents ayant elles-même le même parent.

Les interfaces ont justement été introduites pour répondre à ce problème. En transformant les classes parents en interface, cela revient à ne définir que des classes abstraites (avec des méthodes sans implémentation donc), oblige la classe enfant à spécifier le code de ses méthodes et élimine par conséquent le problème du losange.

[Paleo]

Sekaijin, vous dites : 1/ Au commencement fut On et On créa la Théorie. On y mit les Objets, On y mit l'héritage, et On vit que cela était bon. 2/ Ensuite, ça a coincé du côté des compilateurs sur un stupide problème d'héritage multiple. 3/ Alors On a ajouté les classes amies et personne n'était emballé, puis On a pensé aux interfaces et, à nouveau, On vit que cela était bon.

Et maintenant, la question que vous posez est : puisque en JavaScript nous pouvons simuler de l'héritage multiple, a-t-on encore besoin d'interfaces ?

Ai-je bien résumé ?

[yahiko]

Sauf erreur de ma part, il n'est pas possible de faire de l'héritage multiple en JavaScript, ou alors, on m'aurait menti

L'introduction des interfaces en TypeScript pour ne citer que lui, a justement pour objectif de se rapprocher de l'héritage multiple sans tomber dans ses pièges (le problème du losange)

[SylvainPV]

Si on oublie instanceof, on peut se débrouiller comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Enfant.prototype = mixin(Parent1.prototype, Parent2.prototype, Parent3.prototype)

[Paleo]

Sauf erreur de ma part, il n'est pas possible de faire de l'héritage multiple en JavaScript, ou alors, on m'aurait menti

Tout à fait. Pas plus en ES6 que par le prototype. Les mixins, quant à eux, sont à ranger à côté des traits : c'est de la délégation (enfin c'est vrai qu'on peut discuter).

J'ai de plus un gros doute sur l'existence de la fameuse Théorie qui donnerait le nord à tous les langages de POO. J'ai plutôt l'impression que ces diverses techniques ont été imaginées à tâtons par des créateurs de langages. Les interfaces ne sont plus un palliatif à un stupide souci technique d'héritage multiple, même si elles lui doivent leur naissance. Aujourd'hui le mécanisme des interfaces est un "outil à tout faire" de la POO qui aurait certainement une place de choix dans la Théorie s'il fallait en écrire une.

J'ai découvert pour l'occasion le nouveau mécanisme de l'implémentation par défaut de Java 8. Oracle est un grand spécialiste des usines à gaz.

[yahiko]

J'ai de plus un gros doute sur l'existence de la fameuse Théorie qui donnerait le nord à tous les langages de POO. J'ai plutôt l'impression que ces diverses techniques ont été imaginées à tâtons par des créateurs de langages. Les interfaces ne sont plus un palliatif à un stupide souci technique d'héritage multiple, même si elle lui doive leur naissance. Aujourd'hui le mécanisme des interfaces est un "outil à tout faire" de la POO qui aurait certainement une place de choix dans la Théorie s'il fallait en écrire une.

J'ai découvert pour l'occasion le nouveau mécanisme de l'implémentation par défaut de Java 8. Oracle est un grand spécialiste des usines à gaz.

Clairement, la POO c'est de la grosse bidouille. C'est sans doute la chose la plus importante à comprendre quand on fait de la POO d'ailleurs
Chaque langage a rajouté ses concepts (j'avais oublié les classes "amies" d'ailleurs, merci seikaijin ^^) au petit bonheur la chance, même si c'est caricatural. Ce n'est qu'avec le temps qu'on se rend compte de l'utilité réelle ou non de tel ou tel concept.

Aussi, le concept d'interface est très utile en dehors du cas précis de l'héritage, puisqu'il permet finalement de définir des types et des sous-types, notion plus générale. D'ailleurs, il y avait eu une discussion lors de la release 1.4 de TypeScript pour savoir s'il fallait créer un nouveau mot-clé type définissant un alias de type, ou bien réutiliser le mot-clé existant interface pour cet usage, qui est finalement très proche.

[Invité]

Bonjour,

Je vois beaucoup d'offres d'emploi J2ee, et je voulais savoir si vous pensez que Javascript et Angular.js et node.js suffisent pour la plupart des cas, et que J2ee est démodé , merci. (Ps: le typage dans java c'est lourd à écrire non ?)

Je voudrais savoir si vous pensez que j2ee va durer, et que je dois me mettre dessus ou pas ? Parce que moi j'ai pas envie et je préfère Angular, Jquery et même php !

j'en ai marre de voir plein d'annonces j2ee alors qu'en mon fort intérieur, j'ai l'impression que c'est démodé, lourd, et que c'est pas aussi performant qu'Angular, Jquery et Node.js ou méteor: alors je me trompe ou quoi ?

Qu'est que j2ee a de plus par rapport à angular-jquery-javascript poo etc ... J2ee c'est vieux, y'a pas de plugs ins, c'est chiant à lire. Jquery ça déchire, y'a plein de plug ins. Angular c'est super dynamique . Alors pourquoi y'a encor eplein d'offres d'emploi j2ee alors que c'est démodé? M'etonnerait qu'on puisse faire des apps single page avec j2ee, ou alors ça doit encore en ézcrivant plein de trucs bizarre avec des args[].

Par contre c'est calir que les classes c'est bien avec j2ee, mais les librairies ont l'air super obscures, et quand faut charger une applet java, ça fait penser aux années 90 c'est tout lent un peu naze et tout ? Non ? Je me trompe ou pas ?

[SylvainPV]

j2ee = Java for Entreprise. Non ce n'est pas "démodé", loin de là, et ça fait tourner plein de gros services, services que tu utilises quotidiennement sans t'en rendre compte (fais-moi confiance, je suis dans la bonne boîte pour le savoir).

Node.js ne convient certainement pas à tous les services, en fait je dirais plutôt qu'il convient à une minorité d'usages. On l'utilise ponctuellement aux côtés de JEE pour des tâches très spécialisées de certains services web (du streaming temps réel de données par exemple). Mais pour tout ce qui touche au back et au fonctionnel métier, il faut un langage solide, une plate-forme éprouvée et un bon contrôle des performances. Node est encore très loin de là.

Je précise que je préfère coder en JS qu'en Java, et que je choisis généralement Node pour mes projets persos parce que, hé, c'est nouveau et c'est fun. Mais pour le domaine professionnel, JEE est encore là pour très longtemps. Ceci dit, ça n'empêche pas un codeur JS comme toi et moi de trouver du taf, JavaScript est très populaire et il faut bien que quelqu'un s'occupe du front web non ?

Sinon tous les autres trucs mentionnés (angular jquery etc...) concernent le front et non le back, donc il n'y a rien à comparer.

[ABCIWEB]

J'ai de plus un gros doute sur l'existence de la fameuse Théorie qui donnerait le nord à tous les langages de POO. J'ai plutôt l'impression que ces diverses techniques ont été imaginées à tâtons par des créateurs de langages.

Clairement, la POO c'est de la grosse bidouille. C'est sans doute la chose la plus importante à comprendre quand on fait de la POO d'ailleurs

C'est une définition plutôt "Darwinienne"... Ce "blasphème" me parait également indispensable pour fluidifier la compréhension de la poo

[Paleo]

Je vois beaucoup d'offres d'emploi J2ee, et je voulais savoir si vous pensez que Javascript et Angular.js et node.js suffisent pour la plupart des cas, et que J2ee est démodé , merci.

C'est en tout cas la bonne démarche : choisir sa spécialité parmi les technologies les plus utiles. SylvainPV a raison : Java n'est pas obsolescent. Mais il y a suffisamment d'autres choix parmi les technologies utiles, et JavaScript marche fort.

[Invité]

Ca y est je commence à faire des trucs en Angular.js, C'est la folie ce truc ! Tout les trucs dont je révais se font automatiquement.
Tu changes une variable, elle apparait toute seule à l'écran ! je te racontes pas la simplicité et la puissance du truc ! Waouuuuw ! J'étais étonné par Jquery, mais avec angular, c'est carrément une autre dimension. Et puis quelle clarté dans le code, comme cela devient facile !

j'arrive même à comprendre beaucoup plus facilement le code de killers anglo-saxons, parce que c'est en angular.

[p3ga5e]

Node.js ne convient certainement pas à tous les services, en fait je dirais plutôt qu'il convient à une minorité d'usages. On l'utilise ponctuellement aux côtés de JEE pour des tâches très spécialisées de certains services web (du streaming temps réel de données par exemple).

Je te trouve sévère, en quoi le Framework node.js est-il moins adapté que celui de Java ?
Je pense que node.js est très sous-estimé, en particulier à cause de JavaScript qui le rend populaire que dans les métiers web. Je trouve que c’est donner du caviar aux cochons car la plupart des utilisateurs de node.js ne comprennent pas son intérêt et l’utilisent comme un simple serveur HTTP .

Depuis 3 ans , dans ma boite nous avons abandonné le Framework DotNet au profit de node.js, et nous ne le regrettons pas. Il y a juste une fois ou on eut recourt au DotNet à la place de node.js , a cause d’un problème d’allocation > 2Gb, il faut savoir que le moteur V8 de node limite la taille du tas managée, et cela même sur une plateformes 64 bits

[SylvainPV]

Des échos que j'ai eu des équipes techniques, les raisons généralement évoquées sont :
- le single thread
- l'interfaçage avec l'outillage d'exploitation existant (monitoring, stats, alertes etc...)
- les outils JS pour bosser avec des BDD relationnelles, pas au niveau de ce qui existe en JEE
- le fait que ce soit du JS, avec les conséquences sur les perfs, la fiabilité et la sécurité

On peut débattre de chacun de ces points, et je suis sûr qu'on peut trouver pour chaque un exemple où Node.JS a été utilisé de manière brillante. D'ailleurs j'ai lu que le multi-thread était maintenant tout à fait possible, et que Node se débrouillait de mieux en mieux en matière de scalabilité.

Après avoir utilisé les deux, je n'ai pas d'avis tranché sur la question: c'est vrai que Node.js a du potentiel, et c'est vrai que les gros mammouths comme JBoss commencent à montrer leurs limites. Mais on a tout un écosystème JEE éprouvé depuis des années : je crois que les avantages de Node ne suffisent pas actuellement à convaincre de tout bazarder. Aussi, sur les aspects critiques des applications (paiement ou données sensibles), le facteur risque est trop important pour convaincre les big boss à adopter une techno aussi récente et polémiquée.

Donc l'utiliser partiellement sur certains web-services, pourquoi pas. C'est comme sortir la moto quand on doit faire une course express, et utiliser le monospace le reste du temps. C'est un premier pas pour une adoption à plus grande échelle.

[p3ga5e]

Et voilà tous le problème est là !
Node étant populaire auprès du milieu du Web, il est etudié en fonction des attentes de ce métier, et ce qui est considéré comme un inconvénient ( le mono-threading ) peut être vu comme un avantage pour moi .

J’imagine que tu ne t’es jamais confronté au problème de "deadlocking", c’est une horreur a déboguer, le corriger pour un scénario donné génère 10 nouveaux scénarios d’interbloquages , bref c’est un puits sans fond.
C’est ce qui m’a fâché a tous jamais a avec les environnements multi-threadés, c’est cause de cela que j’ai abandonné le Framework dotnet au profit de node. Node assure qu’un script javascript ne peut être en concurrence, avec un autre script, ce qui ne veut pas dire que les taches asynchrones ne sont pas exécutées sur des threads diffèrent !

Je ne connais pas les problématiques liées au paiement en ligne et données sensible, mais paypal n’a-t-il pas abandonnée Java au profit de Node ?