Le meilleur langage pour le développement cross-platform est-il le C++ ? [Résolu]

[koala01]

Envoyé par youtpout978

Bein là tu es dans le cas du c++, si tu développes en c# ou java et que tu ne veux pas tout casser par la suite en cas de modification tu références des interfaces et non des classes donc tu ne touches en rien à tes classes existantes.

C'est oublier un peu vite que la conception n'est que très rarement ni "tout à fait irréprochable", ni "totalement exécrable".

Tu trouveras de manière quasi systématique à redire même sur le projet le mieux conçu que tu puisses imaginer, tout comme tu trouveras des perles conceptuelles dans le pire des projets jamais conçu

Seulement voilà, c'est un projet qui a déjà couté 30 années Homme (ben oui, cinq ans de développement à une équipe de six ), qui doit remplacer un système développé au fur et à mesure durant quinze ou vingt ans, pour lequel tu es loin d'avoir toutes les analyses fonctionnelles (et on ne parle donc pas des analyses techniques ) parce qu'il y a encore des coins que le client lui-même n'a pas encore exploré, et, bah, tu dois faire avec... Et tu as évidemment interdiction de tout cassé, bien sur

Et donc, tu te trouves face à l'obligation d'assumer des choix qui ne furent pas les tiens, auxquels il t'est impossible de remédier sans avoir à repasser quasiment l'intégralité des fichiers en revue, et avec, malgré tout, l'obligation de faire ce que l'on t'a demandé.

C'est moche, mais faut bien "faire avec"

[youtpout978]

Dans ce cas là tu seras obliger de faire des modifications, mais bon ces problèmes existent dans tous les langages.

J'ai déjà rencontré ce genre de problème et j'ai du impacter une trentaine de fichiers, on pouvais difficilement faire pire comme application.

[Emmanuel Deloget]

Envoyé par youtpout978

Dans ce cas là tu seras obliger de faire des modifications, mais bon ces problèmes existent dans tous les langages.

J'ai déjà rencontré ce genre de problème et j'ai du impacter une trentaine de fichiers, on pouvais difficilement faire pire comme application.

Oh, si

Lorsque j'ai changé de le système de gestion des adresses sur un système GPS haut de gamme, j'ai commencé par designer quelque chose de propre, et ensuite j'ai modifié l'existant pour utiliser le nouveau système.

Je pense que j'ai passé 4 semaines à faire les modifications, impactant aux alentours de 500 fichiers (parce que bon, la gestion d'adresse dans un GPS...). Avec bien évidemment l'impossibilité de faire plus d'un seul commit (on rajoute donc 3 semaines de code review effectuée par deux autres personnes et un voyage aux states pour expliquer le changement et intégrer leurs besoins très spécifiques dans l'application (les américains ont décidé qu'avoir un seul système pour les adresses postales, c'était trop facile. Résultat : sur une seule rue (main street, NY) on compte pas moins de 7 façons complètement différentes de traiter les numéros de rue ; je ne sais même pas comment ils font pour s'en sortir)).

[Bousk]

Envoyé par youtpout978

Les langages comme c# et java peuvent hériter d'une seule classe mais peuvent implémenter une multitude d'interface (je crois que c'est 60 la limite en c#) donc tu peux te passer de l'héritage multiple en utilisant des interfaces pour ces langages.

Et donc tu te retrouves à dupliquer le code d'implémentation de l'interface à chaque fois..
Et la relation "est un" n'est donc pas applicable aux interfaces.

[koala01]

Envoyé par youtpout978

Dans ce cas là tu seras obliger de faire des modifications, mais bon ces problèmes existent dans tous les langages.

Le fait est que tu peux, effectivement, estimer que c'est une erreur de conception de n'avoir pas respecté l'ISP, cela, je te l'accorde.

Mais, d'un autre coté, les interfaces implémentées par Turbine sont par trop générales et leur utilisation aurait pu nous amener à travailler avec des objets avec lesquels il n'y aurait pas eu lieu de pouvoir travailler.

Car, si tu y penses bien, une scie circulaire ou une foreuse implémentent sans doute aussi l'interface "Rotatif", mais n'entre absolument pas dans le corps de métier du cas que j'ai présenté.

Alors, bien sur, je te vois venir avec tes grands sabots et t'écrier "ben, tu devais créer une interface ITurbine, qui héritait de Rotatif et de DebitVolumétrique"...

Ah, mais non, suis-je donc bête... l'héritage multiple est interdit, et je présume qu'on ne peut donc pas faire en sorte qu'une interface hérite de deux autres interfaces...

Je reprends : je prévois que tu vas t'écrier "bien, tu devais créer une interface ITurbine qui héritait de Rotatif et qui implémentait DebitVolumétrique"... Ou peut etre l'inverse...

Mais le problème reste exactement le même que pour l'héritage des classes : Non seulement tu es obligé de faire un choix qui sera peut etre différent de celui de ton voisin, mais, en plus, tu es obligé de créer une interface qui n'apporte en définitive absolument rien (si ce n'est de contenter le langage) !!!

Je suis le premier à plaider pour le respect de SRP, qu'il te suffise de lire mes interventions de ne serait-ce que ces 30 derniers jours pour t'en convaincre.

Mais il y a des limites quand meme !!!

Devoir s'amuser à créer une interface et la classe qui l'implémente (en devant au passage dupliquer le code d'implémentation) juste "au cas ou" (même si très probable) il faudrait faire dériver la classe, ca ne te donne jamais l'impression de faire deux fois le travail, à toi

Si encore, il y avait une raison conceptuelle à faire de la sorte, je l'accepterais, mais que ce soit une restriction imposée par le langage que rien ne justifie conceptuellement parlant, ca, j'ai beaucoup de mal à l'accepter

J'ai déjà rencontré ce genre de problème et j'ai du impacter une trentaine de fichiers, on pouvais difficilement faire pire comme application.

Seulement, ce que tu ne sembles pas comprendre, c'est que ce genre de problème est purement artificiel! :

D'abord, parce que le langage a décidé d'imposer une interdiction qui ne se justifie absolument pas du point de vue conceptuel, ensuite parce qu'il faut bien, à un moment donné, arrêter de penser en terme d'interface pour travailler avec des objets, non

Quand on pense qu'avec l'héritage multiple et dans des circonstances identiques tu n'aurais eu qu'à faire hériter TurboGenerateur de Turbine et de Generateur, sans rien avoir à changer d'autre et sans risquer de casser quoi que ce soit, ca ne te semble pas être une pilule un peu difficile à avaler , d'autant plus que, conceptuellement parlant, et dans le plein respect de Liskov, on peut effectivement dire qu'un TurboGenerateur EST-UN générateur et c' EST-UNE turbine

Ceci dit, m'est aussi arrivé d'avoir à modifier une trentaine de fichiers (et plus) suite à une modification nécessaire mais quelque peu hasardeuse...

Mais je n'ai jamais rien cassé en faisant un héritage qui était justifié

[youtpout978]

Une interface peut implémenter d'autre interface et tu peux obtenir d'une interface l'objet qui l'implémente et le contraire est aussi vrai.

Pour moi et ce n'est que mon avis l'héritage multiple est un faux problème, en tout cas ça n'a jamais été un frein pour le développement des applications sur lesquels j'ai travaillé, peut être faudrait-il que je tombes sur un cas comme le turbogenerateur.

Après on a un peu dérivé du sujet je pense que le mieux quand même est d'en discuter sur le forum .NET par exemple, des membres plus éclairé que moi pourront répondre.

[koala01]

Envoyé par youtpout978

Une interface peut implémenter d'autre interface et tu peux obtenir d'une interface l'objet qui l'implémente et le contraire est aussi vrai.

A coup de "isInstanceOf et de transtypages, sans doute ca fait très OO

Pour moi et ce n'est que mon avis l'héritage multiple est un faux problème, en tout cas ça n'a jamais été un frein pour le développement des applications sur lesquels j'ai travaillé, peut être faudrait-il que je tombes sur un cas comme le turbogenerateur.

Je n'ai jamais dit, non plus, que c'était d'une utilisation courante et régulière (quoi que, c'est encore à voire )...

Mais il y a une chose que meme les javaiste et les Csharpiens ne peuvent nier, c'est qu'il n'y a absolument rien dans les règles de conception ni dans les règles UML qui interdit d'y recourir.

Personnellement, je trouve réellement dommage (pour rester gentil) que n'importe quel langage s'arroge le droit de refuser quelque chose de conceptuellement correct "simplement" parce que c'est source de problèmes potentiels.

En gros, je trouve dommage que ces langages permettent à des incompétents majeurs de se croire bons

Mais bon, je me console en disant que, de toutes manières, vous n'avez simplement pas compris que chaque fois que vous avez une classe qui implémente une interface, vous faites en réalité un héritage multiple (merci l'héritage implicite de Object ), et que c'est encore plus vrai quand votre classe hérite d'une autre ou implémente plusieurs interfaces

[youtpout978]

Envoyé par koala01

A coup de "isInstanceOf et de transtypages, sans doute ca fait très OO

Je n'ai jamais dit, non plus, que c'était d'une utilisation courante et régulière (quoi que, c'est encore à voire )...

Mais il y a une chose que meme les javaiste et les Csharpiens ne peuvent nier, c'est qu'il n'y a absolument rien dans les règles de conception ni dans les règles UML qui interdit d'y recourir.

Personnellement, je trouve réellement dommage (pour rester gentil) que n'importe quel langage s'arroge le droit de refuser quelque chose de conceptuellement correct "simplement" parce que c'est source de problèmes potentiels.

En gros, je trouve dommage que ces langages permettent à des incompétents majeurs de se croire bons

Mais bon, je me console en disant que, de toutes manières, vous n'avez simplement pas compris que chaque fois que vous avez une classe qui implémente une interface, vous faites en réalité un héritage multiple (merci l'héritage implicite de Object ), et que c'est encore plus vrai quand votre classe hérite d'une autre ou implémente plusieurs interfaces

Après c'est un choix des concepteurs de la plateforme, on ne peut pas dire qu'il soit mauvais ou bon et il est aussi lié a d'autre comportement de la plateforme, tout hérite d'objet ce qui permet de faire des méthodes de base qui marcheront avec tous les composants.

Et dans tous les langages il y a des gens qui se croient bon c'est pas propre a java ou c#, c'est la simplicité d'accès à ces plateformes et la demande actuel qui fait qu'il y en a un peu plus dessus mais de là a dire que c'est à cause du langage.

[koala01]

Envoyé par youtpout978

Après c'est un choix des concepteurs de la plateforme, on ne peut pas dire qu'il soit mauvais ou bon et il est aussi lié a d'autre comportement de la plateforme, tout hérite d'objet ce qui permet de faire des méthodes de base qui marcheront avec tous les composants.

Et dans tous les langages il y a des gens qui se croient bon c'est pas propre a java ou c#, c'est la simplicité d'accès à ces plateformes et la demande actuel qui fait qu'il y en a un peu plus dessus mais de là a dire que c'est à cause du langage.

Mais le problème, c'est que vous ne vous rendez pas compte que ces deux langages vous mentent depuis le début...

Quand l'étudiant écrit une classe en java, il peut croire (tant qu'on ne lui a rien dit) que sa classe fait partie d'une hiérarchie tout à fait à part... Non, non, non, pas de chance... elle hérite (sans qu'il n'ai rien demandé !!!) de Object, ce qui fait que, bien malgré lui, sa classe s'insère dans une hiérachie de classes mégalithique qui contient jusqu'à la classe créée par un étudiant à l'autre bout de la terre !!!

Notes bien que je comprend ce choix de conception, mais il est clair (je crois que tu l'auras compris ) que je ne le partage pas .

La deuxième chose sur laquelle le langage vous ment, c'est la notion d'interface, et, pour "faire passer la pilule", il a été jusqu'à introduire trois nouveaux mots clés : interface implements et inherits.

Mais, si tu fais abstraction de ces mots clés, quelle différence y a-t-il entre une classe et une interface

En gros:

1. une classe hérite d'office de Object, et je ne sais plus si c'est le cas d'une interface
2. une interface peut avoir des comportements indéfinis, mais pas une classe
3. une classe peut etre instanciée, mais pas une interface... Seulement, cette troisième différence découle directement de la deuxième parce que les compilateurs ont horreur du vide.

Finalement, une interface, ce n'est jamais... qu'une classe dénaturée

Parce que, si tu regardes en termes de conception, tu constates qu'une classe est substituable à une interface (tu peux passer un objet "implémentant" une interface donnée à toute fonction qui attend cette interface).

Oui, mais... attends un tout petit peu... dés que l'on parle de substitution, on parle du principe de substitution de liskov (le L de SOLID) !!!!

Et que nous dit ce principe encore ?

Envoyé par Barbara Liskov

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

... for objects y of type S where S is a subtype of T...

Ca fait quand même furieusement penser à l'héritage, tu ne trouves pas

En fait, lorsque tu écris le mot clé implements, il ne faut pas te leurrer, en interne ca équivaut à un héritage, et qui plus est, multiple vu que la classe qui implémente une interface hérite d'office de Object!!!

Alors, voilà un point de réflexion intéressant : D'un coté, le langage vous dit "attention malheureux, n'héritez jamais de deux classes en même temps".

Mais, d'un autre coté, il vous dit aussi "Par contre, vous implémentez autant d'interface que vous le voulez".

Mais comme une interface n'est au final qu'une classe dénaturée et que l'implémentation d'une interface correspond exactement à la définition de l'héritage,

• Quel crédit peut on donner à un langage qui nous interdit d'un coté ce qu'il nous autorise (que dis-je... ce qu'il nous incite à faire le plus souvent possible) de l'autre
• Quel crédit peut on accorder à un langage qui nous ment dés le départ sur la base de ses mots clé

Ce n'est qu'un avis personnel, mais, à choisir, je préfère un langage qui ne m'interdit rien mais dont tout me met en garde sur sa complexité, et qui me garanti que je ne devrai pas payer ce que je n'utilise pas

[EDIT]Finalement, je trouve presque cocasse le fait que ce soient en définitive ceux qui ont le plus dans leur culture de recourir à l'héritage multiple qui viennent nous demander quel intérêt on peut trouver à la technique

A leur décharge, comme le langage leur ment, il y ont recours sans même s'en rendre compte
[/EDIT]

[youtpout978]

Pour object je le savais, mon formateur en a parlé dès le début d'apprentissage du langage, après certains mots clef que tu cites n'existe pas en c#.
Et les interfaces ont aussi été crée pour palier aux problèmes d"héritage multiple en évitant les problèmes que l'héritage multiple de classe peut introduire.

Et non interface ne peut pas hérité d'autre chose mais implémenté d'autre interface.

Et une classe peut avoir des comportements indéfini et là c'est une classe abstraite.

[koala01]

Envoyé par youtpout978

Pour object je le savais, mon formateur en a parlé dès le début d'apprentissage du langage, après certains mots clef que tu cites n'existe pas en c#.

Oui, j'ai utilisé les mots clés de java en fait

Et les interfaces ont aussi été crée pour palier aux problèmes d"héritage multiple en évitant les problèmes que l'héritage multiple de classe peut introduire.

Quel problème Celui de l'héritage en diamant sans doute

Non seulement il y a une parade mais, quand on y est confronté, c'est bien souvent parce que l'on n'a pas choisi la granularité suffisante pour l'éviter

Et non interface ne peut pas hérité d'autre chose mais implémenté d'autre interface.

Non, mais comme je l'ai indiqué (j'attends qu'on me contredise sur ce point, d'ici là, je le considère comme acquis ) quand tu utilises le mot clé implements, cela revient strictement au même que si tu recourais à l'héritage

Et une classe peut avoir des comportements indéfini et là c'est une classe abstraite.

Ben oui, ca, on a aussi en C++ ... Mais alors, quelle est la différence entre une interface et une classe abstraite, mis à part le mot clé

Tu tends presque à me donner raison, là...

Tu me dit "une interface ne peut pas hériter d'une aure mais elle peut l'implémenter", alors que ma thèse est que cela revient au même.

Puis tu me dis "une classe, tout comme une interface, peut avoir des comportement indéfinis".

Mais, alors, cela n'indique pas clairement qu'une interface est finalement beaucoup plus proche d'une classe abstraite que vous ne semblez le croire

[Neckara]

Et les interfaces ont aussi été crée pour palier aux problèmes d"héritage multiple en évitant les problèmes que l'héritage multiple de classe peut introduire.

Cela me donne surtout l'impression de résoudre un pseudo-problème en rajoutant un problème encore plus gros...

Je trouve que les interfaces façon C# conduisent à une certaine duplication du code alors que le seul problème de l'héritage multiple reste rare, que souvent il existe des alternatives et qu'il est très facile à résoudre...

[youtpout978]

Une classe abstraite peut avoir des méthodes indéfini et défini, alors qu'une interface n'a que des méthodes indéfini.

Et oui implémenter une interface c'est similaire à un héritage où il faudrait redéfinir toutes les méthodes.

On ne se contente pas d'utiliser que des interfaces non plus on hérite aussi de classe (c'est même souvent le cas), surtout que l'utilité d'un vrai héritage multiple ne se présente que très rarement.

Après il faut peut être avoir fait du c# ou du java pour comprendre le schmilblik, surtout que moi je suis loin d'être un expert et que je ne peux pas non plus tout expliquer.

[Luc Hermitte]

Pour alimenter votre troll: http://blog.algolia.com/need-perform...ile-use-c-cpp/
(je ne crois pas avoir vu passer ce lien)

[bretus]

Envoyé par youtpout978

On ne se contente pas d'utiliser que des interfaces non plus on hérite aussi de classe (c'est même souvent le cas), surtout que l'utilité d'un vrai héritage multiple ne se présente que très rarement.

Il me semble que tu ne comprends pas ce qu'ils disent : Même quand tu "implémentes" des interfaces, tu fais de l'héritages multiple.

[youtpout978]

Envoyé par bretus

Il me semble que tu ne comprends pas ce qu'ils disent : Même quand tu "implémentes" des interfaces, tu fais de l'héritages multiple.

Si je l'ai compris ça.
Je vais arrêter là puisque le sujet du poste à l'origine n'est pas un débat entre l’implémentation de l'héritage multiple suivant le langage.

[Gugelhupf]

Bon sang, je repasse et je vois que vous avez débattu 3 pages sur l'héritage multiple. N'importe quoi

Les interfaces c'est avant tout pour la conception, si on doit penser repenser à la conception dans 10 ans on n'est pas obligé de passer par de l'héritage multiple pour résoudre les problèmes, ça fait un bail que problème est résolu avec les Trait[/URL ou Mixin

[koala01]

Sauf que, si tu y réfléchis bien, tes traits ou mixin... tu vas en souvent en hériter, et parfois même via un héritage multiple

[JolyLoic]

Je dirais plutôt que le problème est résolu grâce à l'héritage multiple, qui permet d'éviter des structures lourdes et demandant beaucoup de code inutile et répétitif, comme peuvent l'être les mixin...

[Niark13]

Je dirais que l'on a plus recours à l'héritage en C++ que dans d'autres langages par exemple :
- pour faire des contrats avec le pattern NVI, cf. l'article de JolyLoic.
- pour faire de la composition sans retaper du code (via héritage privé).

Là où d'autres langages passent par d'autres mécanismes pour résoudre les même problèmes). Forcément, quand on dérive moins, l'héritage multiple se justifie moins (indice : une célébrité a pondu un joli troll dans ma signature).

Pour moi, le RAII est meilleur exemple de point fort de C++ que l'héritage muliple. Les try..finally et autres blocs using sont nettement moins bien parce qu'ils font peser la responsabilité de la libération de ressources sur l'appelant.