Discussion :

[Luc Hermitte]

Il faut reconnaitre que l'existence des interfaces, et l'interdiction de l'héritage multiple généralisé, pousse à ressentir le LSP à défaut de le comprendre -- ce qui n’empêchera pas des dev Java de définir des listes triées avec un extend sur un liste normale (il n'y avait pas un truc comme ça dans une des premières versions de la lib standard de java d'ailleurs ?).

Pour la notion de contrat, je ne suis pas du tout d'accord avec toi, rimram31. La gestion des contrats est un truc tardif en Java et nécessite l'emploi de préprocesseurs externes. En C++, on a en natif le pattern NVI (impossible à mettre en œuvre au milieu d'un héritage multiple d'interface en Java). Dans les deux cas, il s'agit d'hacks bien loin de la propreté de la solution d'Eiffel. [Si tu veux me vendre un langage OO propre, parle moi à la limite d'Eiffel, voire Ruby, mais non pas de Java]

Après, est-ce que le développeur Java va mieux réfléchir aux interfaces ? Hum ... quand on voit les environnements de dev, et certains frameworks (hibernate, c'est bien ça?) qui poussent à un attribut == un setter + un getter, je dirai que c'est tout le contraire. L'objet n'est toujours pas mieux compris malgré les œillères imposées par le langage -- n'est-ce pas pour ça qu'elles existent d'ailleurs ? [et ho, on est trolldi, et c'est pas moi qui ais commencé]. Pour les développeurs C++, parmi les rares qui restent, s'ils ont le malheur de trainer sur des forums, on va tellement leur casser les pieds avec des notions de design qu'au final ils seront sensibilisés au LSP, à la loi de Déméter, et bien d'autres choses. [parfois je me demande même si nous ne fabriquons, sur les forums, des sortes d'évangélistes des bonnes pratiques C++...]

[Luc Hermitte]

Tiens. D'ailleurs, essayons d'avoir un digression sérieuse, et qui aborde ces langages sous un nouvel angle non encore abordé.

Ca se passe comment dans vos forums ?

Je commence.
Chez nous, assez fréquemment on essaie de recentrer vers les vrais problématiques, ce qui dégénère parfois en discussion théorique.

P.ex. dernièrement, j'ai vu passer un message de quelqu'un qui cherchait à rajouter une notion d'ordre sur des entités (du genre deux personnes). Là assez rapidement il a été indiqué à l'OP, que oui techniquement on pouvait arriver à faire ça, mais que sémantiquement, ce qu'il faisait était une hérésie et qu'à terme son truc ne serait pas maintenable, etc, etc. De là discussion sur le bien fondé de solutions bancales répondant à des sujets de TD/TP VS les solutions propres maintenables.

Cette approche est je pense dans la continuité de notre FAQ C++. Beaucoup de points traitent de théorie, et parfois ne correspondent en rien à des questions fréquemment posées. Ce sont plus des éléments, parfois très importants, qui nous aident à répondre et à éviter de re-pondre de grosses tartines théoriques. FAQ qui est à mon gout une FAQ de référence en français (dont j'aimerai bien disposer en anglais quand je traine sur SO, ou quand j'échange avec des collaborateurs étrangers).

Ce qui se passe aussi, ceux qui arrivent dans ce monde de pinailleurs finissent par reproduire ce comportement, parfois de façon un peu trop abrupte. Vous savez, c'est ce moment où l'on commence en en savoir plus, à être capable de répondre, mais où on n'a pas encore acquis la patiente de ceux qui nous avaient accordé de leur temps.

--Pour une vision très ponctuelle de quelqu'un qui répond moins qu'avant, et qui laisse à d'autres de soin de compléter, de me contredire, etc--

[koala01]

Je crois à ce sujet que l'on "devient" pinailleur quand on programme en C++, alors qu'on aura sans doute moins tendance à le devenir en java.

Le fait est que, de par les restrictions que java impose en terme de choix de conception, un "simple" ressenti de LSP suffira sans doute, quitte à en arriver à avoir une liste triée qui hérite de liste alors que c'est conceptuellement aberrant, à cause des posts conditions et autres invariants.

C++ étant, par contre, beaucoup plus permissif, on en arrive très rapidement à se rendre compte qu'une conception bancale se transforme, de manière quasi systématique, en un fusil chargé dont le coup ne demande qu'à partir au pire moment qui soit, comme de juste.

Le fait de rappeler les principes de base et d'arriver à ce que les autres les admettent et les comprennent (afin d'être en mesure de les appliquer correctement) revient donc en quelque sorte à inculquer un "réflexe de survie" : comprend les principes, respecte les en tous temps, et ton projet évoluera sans problème.

De par les restrictions qu'il impose en terme de choix de conception, java permet d'être un peu moins pinailleur, même si une compréhension identique des grands principes ne ferait sans doute aucun mal à ses utilisateurs

[deadalnix]

De son origine, destiné a permettre le contrôle d'une multitude d'équipements, la notion de "contrat" (interface) est prépondérante en Java et largement utilisée, elle est bien entendu possible en C++ mais moins "naturellement" mise en oeuvre.

Je te conseille de regarder Eiffel ou D pour savoir ce que sont des contrats.

[_skip]

Je crois à ce sujet que l'on "devient" pinailleur quand on programme en C++, alors qu'on aura sans doute moins tendance à le devenir en java.

Le fait est que, de par les restrictions que java impose en terme de choix de conception, un "simple" ressenti de LSP suffira sans doute, quitte à en arriver à avoir une liste triée qui hérite de liste alors que c'est conceptuellement aberrant, à cause des posts conditions et autres invariants.

J'aurai peut être admis que tu dises qu'on devient pinailleur en C++ dans le sens où l'on fait bien attention à la durée de vie des objets, aux pointeurs qui sortent d'une classe, qui est propriétaire et responsable de disposer ce qui est pas forcément le cas dans un langage managé. Même si je pense que tu finis par avoir les mêmes réflexes lorsque tu manipules des gros objets.

En revanche, prétendre qu'on arrive plus facilement à des aberrations comme hériter de liste pour en avoir une version triée (alors qu'on a des SortedSet, des TreeSet etc...), et se retrouver avec une interface inadaptée (forcément si tu regardes les méthodes de List) c'est un peu fort. Mais je crois que je vois ce que tu as voulu dire dans le fond.

Le fait de rappeler les principes de base et d'arriver à ce que les autres les admettent et les comprennent (afin d'être en mesure de les appliquer correctement) revient donc en quelque sorte à inculquer un "réflexe de survie" : comprend les principes, respecte les en tous temps, et ton projet évoluera sans problème.

Evolutivité . Justement je trouve que dans le monde java on trouve les pratiques les plus abusives en matière de conception (tout ce qui tourne autour du 3/tiers strict, des applications multicouches, des frameworks, les mappings objet-relationnels et tout). Je dis abusives car elles conduisent bien trop souvent à des applications surarchitecturées, d'une complexité impressionnante pour finalement un besoin très simple.

Comme dans ce post humoristique que j'ai cité sur la taverne, on dirait qu'on ne supporte pas de résoudre simplement les problèmes. Faut qu'on aille chercher le gros artifice de surconception censé rendre l'application meilleur et qui rate complètement sa cible.

[rimram31]

Euh... pardon ?
En quoi JAVA pousserait plus à l'utilisation d'interface que C++ ?

Je te conseille de regarder Eiffel ou D pour savoir ce que sont des contrats.

La théorie est une chose, la réalité en est une autre, Eiffel permet de définir des contrats, probablement mieux qu'en Java, oui mais Java l'a fait.

Un constat, il existe pas moins de 350 JSR (http://fr.wikipedia.org/wiki/Java_Sp...ation_Requests) réunissant de nombreux acteurs de l'industrie dont l'objectif n'est autre que de définir des contrats pour des grandes "familles de besoin". Et ces travaux ne sont pas que théoriques puisqu'ils aboutissent a des implémentations de ces divers acteurs concrètement utilisables. Un autre, la quantité des travaux java des différentes communautés de développeur internet, on pourrait ne citer que la fondation Apache.

Probablement parce qu'il était "à la mode" ces dernières années, Java a formidablement fait avancer ces sujets comme avec OSGi aujourd’hui (montrant d'ailleurs qu'en poussant la question assez loin, on se prend les pieds dans la complexité de la gestion des dépendances ...)

Probablement par ignorance, mais je ne connais pas d'équivalent, aussi largement utilisé dans l'industrie, dans d'autre technologies, d'autres langages.

[rimram31]

Je complèterai par contre par un retour d'expérience pour moi totalement incompréhensible: Java pousse-t-il un développeur a construire son architecture sur ces principes de base? ben non et a mon grand regret. Heureusement qu'on leur fournit JDBC sinon, ils me recoderaient aussi sec une interface database dégueulasse. Vécu tous les jours, plus que de passer une heure a chercher sur internet la solution qui s'offre a eux, ils vont chercher a vous convaincre que leur idée est bien meilleure pour aboutir toujours au même résultat, un truc immonde qui marche une fois sur dix.

Pour finir, un vrai défaut a Java, le sentiment qu'il donne au développeur que "Java s'occupe de tout". Vécu, un programme Java qui ne ferme pas ses sockets, ses fichiers (et qui fait mourir une plateforme en deux minutes!) ou qui va allouer la totalité de la mémoire d'un serveur distribué ...

[deadalnix]

Tu confonds contrat et API.

[rimram31]

Tu confonds contrat et API.

Absolument pas car une JSR a vocation de définir un standard, qui se préoccupe de "ce dont le client a besoin" et non pas de "tout ce que je suis capable de faire". On joue peut-être sur les mots mais comme je le dis plus haut, ces travaux en Java sont bien une réalité, pas uniquement un vœu ou une possibilité technique.

[Mat.M]

Salut,

Je complèterai par contre par un retour d'expérience pour moi totalement incompréhensible: Java pousse-t-il un développeur a construire son architecture sur ces principes de base? ben non et a mon grand regret. Heureusement qu'on leur fournit JDBC sinon, ils me recoderaient aussi sec une interface database dégueulasse.

je n'ai rien compris à cette intervention ; des interfaces pour des bases de données on peut très bien faire ça en C++ avec l'OPI ODBC comme on peut faire cela avec Java et JDBC comme mentionné..
en C++ il y a Qt ou MFC qui offrent des classes pour gérer les bases de données;

Vécu tous les jours, plus que de passer une heure a chercher sur internet la solution qui s'offre a eux, ils vont chercher a vous convaincre que leur idée est bien meilleure pour aboutir toujours au même résultat, un truc immonde qui marche une fois sur dix.
.

je ne suis pas d'accord ; Internet n'apporte pas toujours la solution que l'on cherche
Souvent en informatique on est obligé de faire des développements spécifiques on est contraint de se creuser la tête et la solution n'est pas forcément sur Internet.
Cela ramène au débat "faut-il réinventer la roue ?".
Peut-être que le problème de Java ( et de C#/NET ) c'est qu'on a toute une collection de classes à disposition en tous genres (réseau,bdd etc..)alors la personne qui dirige le projet se dit :" chouette on va pouvoir faire tout ce que l'on veut et résoudre tous les problèmes" alors que ce n'est pas vrai..
j'ai l'impression que c'est un peu un miroir aux alouettes comme avec les outils RAD ( Visual Basic et Delphi )des années 90...

[rimram31]

Salut,

je n'ai rien compris à cette intervention ; des interfaces pour des bases de données on peut très bien faire ça en C++ ...

Je parle de standardisation, pas de bibliothèque, comme je le dis plus haut dans une API, se mettre a la place du client, pas celle du fournisseur. Et par voie de conséquence, tout module complémentaire, puisque développé sur des standards, sera plus facilement réutilisable etc, etc ...

je ne suis pas d'accord ; Internet n'apporte pas toujours la solution que l'on cherche...

Il ne t'apportera pas ton projet tout fait sur un plateau :-) Mais, à moins de travailler dans un secteur très particulier, qu'il s'agisse de composants, d'approches, de technologies ... il est rare de ne pas pouvoir décomposer un projet en un ensemble de problématiques presque "classiques", le spécifique se réduisant a pas grand chose.

Si ce n'est pas des composants directement utilisables, c'est à minima des travaux, des réflexions qu'il est toujours très utile de découvrir.

[Logan Mauzaize]

Tiens. D'ailleurs, essayons d'avoir un digression sérieuse, et qui aborde ces langages sous un nouvel angle non encore abordé.

Ca se passe comment dans vos forums ?

Je commence.
Chez nous, assez fréquemment on essaie de recentrer vers les vrais problématiques, ce qui dégénère parfois en discussion théorique.

P.ex. dernièrement, j'ai vu passer un message de quelqu'un qui cherchait à rajouter une notion d'ordre sur des entités (du genre deux personnes). Là assez rapidement il a été indiqué à l'OP, que oui techniquement on pouvait arriver à faire ça, mais que sémantiquement, ce qu'il faisait était une hérésie et qu'à terme son truc ne serait pas maintenable, etc, etc. De là discussion sur le bien fondé de solutions bancales répondant à des sujets de TD/TP VS les solutions propres maintenables.

Cette approche est je pense dans la continuité de notre FAQ C++. Beaucoup de points traitent de théorie, et parfois ne correspondent en rien à des questions fréquemment posées. Ce sont plus des éléments, parfois très importants, qui nous aident à répondre et à éviter de re-pondre de grosses tartines théoriques. FAQ qui est à mon gout une FAQ de référence en français (dont j'aimerai bien disposer en anglais quand je traine sur SO, ou quand j'échange avec des collaborateurs étrangers).

Ce qui se passe aussi, ceux qui arrivent dans ce monde de pinailleurs finissent par reproduire ce comportement, parfois de façon un peu trop abrupte. Vous savez, c'est ce moment où l'on commence en en savoir plus, à être capable de répondre, mais où on n'a pas encore acquis la patiente de ceux qui nous avaient accordé de leur temps.

--Pour une vision très ponctuelle de quelqu'un qui répond moins qu'avant, et qui laisse à d'autres de soin de compléter, de me contredire, etc--

Ca fait un moment que je traine plus trop sur la partie Java mais l'essentiel des questions concernent l'utilisation d'une API que ce soit l'API standard ou une énième API.
La second problèmatique la plus traitée doit être l'intégration des concepts de l'API. Si je prend "Hibernate" par exemple, les gens ignorent souvent le "cache de second niveau" et la notion d'identité.
Enfin seulement il y a des questions autour de comment organiser un jeu de classes et leur communication. Et s'il y a quelques années la grande beauté théorique était pronée, désormais on s'intéresse beaucoup plus aux contraintes du demandeur. Par exemple le cas de la liste triée est assez intéressant. D'un point de vue technique qu'est-ce qui différencie les deux listes ? L'absence de contrôle de l'emplacement en insertion. Si je faisais une nouvelle "collection", je perdrai la capacité à utiliser une liste triée dans les APIs qui "lisent" des listes ; par contre je sacrifierai sa capacité à accélérer les recherches (sauf si j'utilise intelligemment les méthodes "contient?" et "indexOf"). Aujourd'hui les discussions tendent plus à soulever les loups qui posent problèmes à l'instant présent.
Les développeurs Java admettent de plus en plus qu'ils ne savent pas de quoi demain sera fait. Et que de toutes façons, quand l'heure viendra de faire quelque chose de générique, il faudra développer de toutes façons alors autant adapté convenablement à l'instant le plus approprié, c'est-à-dire quand ca se présente.

[rimram31]

...mais l'essentiel des questions concernent l'utilisation d'une API que ce soit l'API standard ou une énième API...

Peut-être, mais en comparant Java a C++ il est difficile de ne pas citer l'acronyme Learn Once Use/Repeat/Work everywhere et je peux comprendre que Mat.M plus haut n'ai rien compris a mon intervention, s'il n'a pas ça en tête. Même s'il faut reconnaitre que les JSR ne sont pas toujours la panacée, ce processus ayant accouché de sacré usines a gaz (genre les EJB, ce qui explique leur échec relatif).

[Bousk]

Peut-être, mais en comparant Java a C++ il est difficile de ne pas citer l'acronyme Learn Once Use/Repeat/Work everywhere

FAis-tu encore du C++ ?
Parce que toutes les libs/framework récents permettent la même chose.
Qt pour ne citer que lui..

[rimram31]

FAis-tu encore du C++ ?
Parce que toutes les libs/framework récents permettent la même chose.
Qt pour ne citer que lui..

Non, 10 ans de C puis 10 ans de Java, pas alternativement :-) mais je disais plus haut que la différence était dans la genèse de la technologie. Java, plutôt Sun a l'époque, l'a voulu (marketing) et conçu (techniques) comme ça et c'est une des raison majeures de son succès dans l'industrie. Que d'autres technologies s'en soient inspirées par la suite, ça ne peut qu'être un bien.

Toutefois, tu ne réponds pas a ma question plus haut, existe-t-il un équivalent du JCP? A savoir permettre a plusieurs acteurs de l'industrie informatique de se réunir pour travailler sur un standard, ce n'est pas tout a fait la même chose qu'un outil, fut-il open source, qui se veut devenir le standard.

[Luc Hermitte]

C'est le cas de la norme C++ qui est ISO et ANSI. Le C++ n'appartient à personne, et ce n'est pas une histoire d'open-source. Java avait suivi un chemin différent -- dans mes souvenirs, la main mise de Sun sur le Java était bien plus importante que celle de n'importe quel autre acteur dans le cas du C++.

Et comme d'autres l'avaient fait remarqué dans le passé, si Sun avait investi dans le C++ ce qu'il avait investi dans le Java la situation aurait été différente.

[Bousk]

Oui et le C ou C++ a aussi été vendu au début comme "multi-plateforme", et on sait tous ce que ça signifie vraiment, réécrire du code spécifique plateforme au plus bas niveau.

JCP ? un commité de standardisation ? Je te rassure il y en a également... ce n'est pas parce que le langage ne propose pas de fioriture tape à l'oeil en standard (typiquement le fenetrage) qu'il n'y a pas de standard.

Du coup, tu ne fais pas de C++, tu es clairement pro-JAVA, mais tu ne sembles pas savoir grand chose du langage que tu essayes de "dénigrer" dans tes propos.. et aucun de tes arguments avancés n'est bien probant amha.

[souviron34]

Java avait suivi un chemin différent -- dans mes souvenirs, la main mise de Sun sur le Java était bien plus importante que celle de n'importe quel autre acteur dans le cas du C++.

Et comme d'autres l'avaient fait remarqué dans le passé, si Sun avait investi dans le C++ ce qu'il avait investi dans le Java la situation aurait été différente.

Oui et le C ou C++ a aussi été vendu au début comme "multi-plateforme", et on sait tous ce que ça signifie vraiment, réécrire du code spécifique plateforme au plus bas niveau.

je ne parleris pas de C++, que je ne pratique pas, mais simplement, historiquement, le pourquoi de Java par SUN est très simple :

ce n'est pas une main-mise.

SUN, avec HP, IBM, DEC, et Silicon (plus MIT), avaient créé le X-Consortium, pour unfieir le graphisme via X11.

M$ n'a jamais voulu ouvrir sa machine aux standards (quand ça n'était pas l'ouvrir tout simplement : Linus Torwald a créé Linux parce que de 93 à 95 m$ ne livrait que des machines soudées, où on ne pouvait accèder à rien de l'interne).

Le mouvement depuis le milieu des années 70 était à l'unification : vers unixoides, et vers X11.

SUN, donc membre du consortium X11, a pris l'initiative au sein du X-Consortium d'essayer de faire un pont (pour rappel : VB, Delphi, ou VC++ n'existaient et ne produisaient que des choses Windows) entre Windows et le reste (// à Torwald et Linux, comme l'avait fait SCO avant en s'orientant vers X11), en développant quelque chose qui pouvait s'appuyer sur X11 d'un côté ou sur la lib Win de l'autre.

D'où la notion de VM et de bytecode. C'est uniquement au départ pour s'arranger avec M$, qui était seul dans son coin..

Ce n'est donc pa une question de "main-mise", bien moins que M$ avec VB ou VC++ (disons avec sa WindowsAPI).. Au contraire, ils étaient engagés depuis 15 ans dans un mouvement global de standardisation.

Et SUN n'avait pas 'intérêt à investir dans C++, pour la raison invoquée plus haut : VC++ était pour M$ jusqu'en 1999-2000 environ... et ils chechaient la compatibilité avec tous les autres constructeurs...

Contrairement à une idée répandue, l'industrie possédait beaucoup de minis ou PC avec linux, Unix, ou d'autres unixoides ou équivalents, et pour beaucoup de programmes C++ n'était pas du tout utilisé, sauf en test de dév à partir de 1997-1998... Les devs sur PC et M$ se fasait pour beaucoup avec VB ou Delphi...


(PS: pour rappel, alors que les sockets asynchrones (et donc les serveurs/servces "en attente" étaient standard sur unixoides depuis plus de 20 ans, ils n'ont débarqués réellement sur Windows que fin 1999-début 2000, les serveurs/services jusque-là bouclant 1 fois par seconde pour surveiller les ports)

[Luc Hermitte]

La main-mise à laquelle je faisais allusion était celle de Sun à l'égard de son Java. Les choses semblent s'être plus ouvertes par la suite.

Après de 1997-2002 je faisais du dev C++ sous Solaris initialement, avant migration totale du code vers windows pour des objectifs imposés de plateforme finale et de COM.
Sun avait d'ailleurs un super compilo. Un des meilleurs en termes d'optimisation même pour le C++. Est-ce que s'engager vers la voie C++ aurait été faire le jeu de microsoft ? Je n'en suis pas sûr.

[rimram31]

C'est le cas de la norme C++ qui est ISO et ANSI. Le C++ n'appartient à personne...

L'ambition de Sun allait bien au delà du seul langage avec "ses JSR" puisqu'il est question de normaliser des besoins "récurrents" des applications, il n'est qu'à parcourir la liste des JSR (http://fr.wikipedia.org/wiki/Java_Sp...ation_Requests) incluant par exemple une API USB, Bluetooth ...

Oui et le C ou C++ a aussi été vendu au début comme "multi-plateforme", et on sait tous ce que ça signifie vraiment, réécrire du code spécifique plateforme au plus bas niveau...

C'est que tu méconnais Java, les JCP ne sont pas que du bool sheet marketing, ces standards sont très concrètement utilisés dans l'industrie avec les avantages qu'ils promettent. Le succès de Java dans le monde du web, je l'ai connu au début des années 2000, a plus tenu a l'existence du JSDK et de JDBC qu'au langage lui-même et son implémentation qui a posé beaucoup de problèmes et, pour autant, n'a pas découragé les acteurs. Il est des critiques que l'on peut faire aux JSR, mais ce n'est pas, je pense, le lieu de ce débat.

Je ne dénigre absolument pas C++, si tu me posais la question sur le fond, après avoir parcouru a peu près l'essentiel des langages qui ont vu le jour depuis 30 ans, je n'en dénigre aucun d'entre eux et en ait conclu qu'il est des technologies adaptées a chaque contexte (et pas toujours utilisables d'ailleurs ... contexte humain oblige). C'est pourquoi j'ai finit par m'intéresser a la genèse d'une technologie ou d'une idée, sa vision, car si on peut toujours a peu près tout faire avec n'importe quoi, c'est plus facile, mais surtout plus sûr, de le faire avec celle qui avait en tête dès le départ les objectifs que tu recherches.