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 ?