Je trouve que cette assertion est bien moins vraie aujourd'hui qu'il y a quelques années. Il y a sûrement eu un effet de raz le bol, face à un effet de mode qui annonçait que Java allait résoudre tous les problèmes de tout le monde, parce que c'est de l'objet (mais de l'objet amputé) et l'objet c'est magique, et que Java que ça tourne partout, et que le GC de Java c'est parfait, etc.
Aujourd'hui, il y a un peu deux pendants à la communauté C++, ceux qui défendent le C++ à l'ancienne coûte que coûte, et ceux qui font (ou voudrait faire, mais n'ont pas toujours le choix) du C++ moderne. Les premiers te diront que Java c'est naze parce que pour être sérieux, il faut gérer tes ressources manuellement. Les seconds te diront que les premiers écrivent du code qui fuit sa race ou alors dépense bien trop cher pour faire manuellement ce qu'on sait efficacement automatiquement.
Pour autant les seconds ne sont globalement pas fan des GCs puisque justement ils ont l'habitude d'un système où la gestion est automatique sans GC. Ils ne sont pas fan non plus de l'absence de certaines fonctionnalités de l'objet, de la manière de faire du générique en Java ou encore de l'absence d'un mot clé indispensable en C++ : const.
Côté Java, il y a pas mal de développeurs qui ont eu un enseignement préhistorique de C++ (et qui en gardent donc un très mauvais souvenir), de fait leur connaissance de C++ (pour beaucoup, pas pour tous) se base sur la connaissance du C++ à l'ancienne donc gestion manuelle des ressources, pointeurs, etc. Ce qui leur fait dire que c'est un langage qui est atrocement compliqué à utiliser quoi qu'il arrive. Ce qui n'est plus le cas depuis quelques années déjà.
Mais bon. Ce qu'il faut surtout comprendre, c'est que des langages, on en a plein et qu'ils ne sont que ce qu'ils sont : des outils.
En fait, beaucoup de devs crachent sur Java. Pas nécessairement des devs C++ ; je connais des devs PHP ou encore C# qui détestent ce langage. Mais pourquoi ? On peut trouver plein de réponses à ces questions sur le net.
Personnellement, j'ai plusieurs raisons de ne pas aimer Java (la liste n'est pas complète) :
Les messages d'erreurs : outre le post de MysteryDash, je garde un atroce souvenir des messages d'erreurs de Java. Dix fois trop long alors que ça pourrait tenir en une ligne.
Le GC.
L'orienté objet version Java : beurk. Clairement, je suis pas fan du tout. Par exemple, Math n'a, selon moi, pas une sémantique de classe. Il serait bien plus logique d'avoir des fonctions types sqrt, pow... dans un namespace. Pas une classe statique avec tout plein de méthodes statiques. Après, bon, ce n'est que mon avis.
Étrangement, l'énorme majorité des devs Java que je connais, c'est vraiment pas des flèches. Coïncidence ? Peut-être. Mais je reste persuadé que Java tel qu'il est enseigné dans la plupart des cas apprend de très mauvaises pratiques (par exemple, getMachin, setTruc, même mes IDEs proposent la création automatique de getters / setters...)
Parallèlement à cela (et un peu hypocritement), j'utilise Java lorsque je fais des applications sur Android et je ne m'en plains pas. Enfin, si un peu. Beaucoup. Des fois.
Côté C++, c'est effectivement plus subtil. Cf le post de Ksass.
J'ai connu plus de devs Java qui crachent sur C++ que l'inverse.
"Son modèle objet est une catastrophe". "C++ est honteusement compliqué". "L'héritage multiple, wtf ?". (tout en gardant à l'esprit qu'implémenter plusieurs interfaces est une forme d'héritage multiple ) Et j'en passe.
Ardakaniz a écrit:
C'est pour ça que j'ai dit:
Ardakaniz a écrit:
Je pèse sûrement un peu les mots mais en gros, c'est ça.
Mais les devs c++ critiquent le java (syntaxe et autre) et inversement
Pour le coup, c'est qu'un avis perso, mais je suis moyennement d'accord avec le poste du dessus.
Et surtout concernant la portion getter / setter. En fait, l'encapsulation est un principe de programmation OO, le fait que C# ait utilisé des propriétés (et personnellement, j'ai un peu de mal avec ce concept) plus que des accesseurs, c'est ça que je trouve dommage.
L'héritage multiple est aussi pour moi quelque chose de peu concevable, le fait de surenchérir l'extension d'une classe à d'autres multiples classes rend le programme bien trop compliqué, et fait clairement preuve d'un énorme problème de conception à la base ("Keep It Simple Stupid").
L’implémentation d'interface a, au contraire, beaucoup plus de sens. On a une notion de contrat (et l'interface existe uniquement pour cette notion la, sinon on ferait de l'abstraction uniquement avec des abstracts).
Pour en revenir au poste de base, ces débats sont uniquement (et tu peux le voir par rapport à ma réponse pas du tout objective et basée sur mon expérience) qu'il s'agit surtout d'un débat pour savoir qui a la plus grosse. Y'a des pro open source, ya des pro Microsoft, et quand tu travaille sur un truc, le reste est forcément moins bien. L'humain a besoin de se mettre en avant au sein de sa communauté pour prouvé qu'il en sait plus que les autres, et qu'il a raison : "la loi du plus fort". c'est uniquement ca
Le manager pragmatique ne cherchera pas le "quoi" de l'erreur, mais le "pourquoi" de celle-ci
Et surtout concernant la portion getter / setter. En fait, l'encapsulation est un principe de programmation OO, le fait que C# ait utilisé des propriétés (et personnellement, j'ai un peu de mal avec ce concept) plus que des accesseurs, c'est ça que je trouve dommage.
Le but de l'encapsulation c'est de préserver les invariants des objets, pas d'empêcher les modifications directes (si une valeur n'entre pas en compte dans l'invariant, il n'y a aucune raison de la rendre privée). Les getters et les setters sont le meilleur moyen de péter l'encapsulation. Les deux autres principaux effets néfastes c'est des classes pensées en terme de données plutôt qu'en terme de service (les objets sont des fournisseurs de services, pas de stockage) et d'exposer le fonctionnement interne de la classe (ce qui viole au moins partiellement le DIP). Si les getters ont parfois un sens (il est légitime pour certaines classes de fournir un tel service), les setters sont très souvent de gros fails (en plus de ne pas respecter Démeter).
Skahrz a écrit:
L'héritage multiple est aussi pour moi quelque chose de peu concevable, le fait de surenchérir l'extension d'une classe à d'autres multiples classes rend le programme bien trop compliqué, et fait clairement preuve d'un énorme problème de conception à la base ("Keep It Simple Stupid").
L’implémentation d'interface a, au contraire, beaucoup plus de sens. On a une notion de contrat (et l'interface existe uniquement pour cette notion la, sinon on ferait de l'abstraction uniquement avec des abstracts).
L'héritage multiple (et même l'héritage en diamant) est tout à fait concevable même s'il est très rare d'en avoir besoin. Si une classe et le service qu'on attend d'elle est effectivement le sous-type de deux autres classes et que la substituabilité est présente, il n'y a pas de raison de l'interdire. Cela permet également d'avoir de l'implémentation par défaut sur les interfaces sans ajouter de choses au langage.
Si l'on garde en tête que l'héritage est une relation forte qui doit respecter la relation "est-un" et le LSP (et c'est ce qu'on a besoin de vérifier en fait : pour toute fonctionnalité, post-conditions au moins aussi fortes, pré-conditions au moins aussi faibles, invariants compatibles), on a pas de problèmes à faire ces manipulation quand elles sont nécessaires.
J'ai beaucoup appris de ton post, de manière générale Ksass, et je voyais pas l'encapsulation sous cette angle (merci pour la manière ton tu as écris ca dailleurs)
Cependcant, les setters (que tu n'as pas l'air d'aimer :p), je les trouves vraiment bon a utiliser. Quand il s'agit notamment d'injecter une autre implémentation d'un service (et notamment pour les tests unitaires et le travail sous format TDD) sans avoir a recréer un objet, ou pour modifier le comportent de ton objet parent dynamiquement à l’exécution.
Ce que tu as l'air de dire, c'est que tu préférerais utiliser des attributs public plutôt qu'avec des accesseurs ?
Et je voulais rajouter que tout les objets ne servent pas forcément de services (DTO par exemple), après j'ai peut être pas cerné le sens dans lequel tu as tourné ta phrase
Le manager pragmatique ne cherchera pas le "quoi" de l'erreur, mais le "pourquoi" de celle-ci
Quand il s'agit notamment d'injecter une autre implémentation d'un service (et notamment pour les tests unitaires et le travail sous format TDD) sans avoir a recréer un objet, ou pour modifier le comportent de ton objet parent dynamiquement à l’exécution.
Il faudrait être plus précis je pense. Notamment parce que l'idée de modifier le comportement d'un objet en cours d'exécution implique quand même qu'on doit conserver au moins des contrats compatibles avec tout autre objet qui aurait accès à l'interface en question et qui a potentiellement une connaissance plus complète de son type que nous (et là c'est une phrase tordue, c'est pour ça que sans plus de détails difficile de dire répondre exactement).
Skahrz a écrit:
Et je voulais rajouter que tout les objets ne servent pas forcément de services (DTO par exemple), après j'ai peut être pas cerné le sens dans lequel tu as tourné ta phrase
A mon sens, ici, on a tendance à sortir de l'objet oriented pour passer dans le data-oriented. Quand c'est maîtrisé et qu'on a une couche très fine (typiquement ne faisant que le pont entre une DB et le reste de l'appli), c'est envisageable d'autant que pas mal d'ORM feront qu'on aura même pas à écrire le code. Le problème, c'est que cette manière de faire a tendance à intégralement contaminer les projets.
J'ai retrouvé ça, l'avis de quelqu'un de bien plus compétent que moi sur le sujet :
je veux faire une application web de essayages des lunettes en ligne avec le webcam .est ce que c'est possible avec le symfony2? et quel sont les meilleur moyenne??
je veux faire une application web de essayages des lunettes en ligne avec le webcam .est ce que c'est possible avec le symfony2? et quel sont les meilleur moyenne??
quelqu'un peut il m'aider ???
Ouaip, en Java, c'est un super langage, on en parlait justement.
Parce que Darwin. (les mauvais devs ne survivent pas au C++, donc ils font du Java)
Parce que les devs Java ne savent pas faire de la POO. (Beaucoup de devs C++ non plus... mais on leur tape dessus)
Parce que les devs Java ressortent les arguments marketing d'Oracle sans savoir prendre de recul. (Le Java, c'est plus portable. Le GC permet de simplifier la gestion de la mémoire. L'héritage multiple, c'est mal, nous on a des interfaces. Etc).
Parce que l'on ne peut pas faire du bas niveau en Java si on a besoin.
Parce que l'on ne peut pas faire du haut niveau en Java si on a besoin.
Parce que le Java n'a pas de vrai méta-prog avec ses templates.
Parce que, même si c'est pas bien de taper sur un plus faible que soit, cela défoule de taper sur le Java.
Fight !
(Miam, une discussion pour me nourrir, ça fait longtemps...)
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.