Discussion :

[gl]

Je n'ai probablement rien compris, mais j'ai souvent l'impression que le pattern façade est une supercherie... Soit les fonctions utilisées par la façade sont bien faites, et la façade est inutile, soit elle sont inadaptées, et la facade est un cache misère...

Je vois au moins deux intérêts à une façade :

• Encapsuler une API bas niveau dans une API de plus haut niveau, probablement plus simple à utiliser (peut-être est-ce ce que tu entends par "l'API d'une librairie tierce est une façade").
• Encapsuler une bibliothèque A dans une couche présentant l'API de la bibliothèque B afin de pouvoir facilement intervertir les deux bibliothèques (ou plus généralement présenter une API unique pour plusieurs implémentations différentes). Les raisons de cette manœuvre peuvent être multiple : remplacement au pied levé de B par A avec un impact nul ou minimal dans le code, choix d'une implémentation parmi plusieurs, système de plug-in, etc.

[Mac LAK]

Pour revenir au sujet initial :

Depuis la naissance de C++ et la communauté se focalise plus sur la technique et ces astuces.

D'un autre côté, C++ reste un langage de bas niveau, même s'il est assez haut par rapport aux autres langages bas niveau... Se dissocier de la technique, ou des performances, c'est simplement s'être planté de langage : si tu n'as aucun besoin spécifique de performances et/ou de proximité avec le matériel / OS, tu as bien d'autres choix que C++ qui seront largement plus pertinents, notamment en ce qui concerne le temps de développement...

Malheureusement les sociétés commencent à fuir c++ à cause de sa complexité puisqu'on perd beaucoup de temps au niveau des couches techniques or l'essentiel c'est la couche métier.

Viens bosser dans l'embarqué, tu apprendras à fuir la STL, Boost et à implémenter à l'ancienne, à la barbare, avec le clavier entre les dents et le fer à souder sur l'oreille...

Pour ma part, je sais que dans ma boîte, c'est un peu le contraire : on a toujours du mal à trouver de "bons" développeurs C++ bas niveau, c'est à dire des gens qui ne passent pas la moitié du temps à regretter un framework Java ou à chercher une librairie toute faite (qui sera poussive et pèsera 40 Mo dans le code, mais ils te diront de mettre un CPU plus puissant et plus de RAM...).

Tout dépend du type de travail que tu fais, et du type d'applications réalisées. Encore une fois, on peut actuellement presque tout faire avec presque tous les langages, mais certains choix sont au mieux malheureux (IHM de haut niveau très complexe en C++/MFC "de base"), au pire stupides (programme bas niveau en Java avec trois tonnes de JNI pour assurer les fonctions).

Quand la communauté C++ s'intéressera plus a la conception ?

Qui te dit qu'on ne conçoit pas ? Concevoir n'est pas synonyme de "chercher un beau framework tout prêt", c'est aussi s'adapter aux contraintes matérielles et logicielles, tenir les performances exigées et, si c'est possible, les délais de développement... Tout dépend si tu as une obligation de moyens ou une obligation de résultats !!
Si c'est une obligation de résultats, tenir les performances n'est pas une option ou un but théorique, ça DOIT être la réalité... Peu importe les délais ou presque, d'où l'importance d'un bon chiffrage à la base et le fait de savoir que, pour le client, les performances sont cruciales.

Ça fait 10 ans que je fais du c++ et je sais qu'un débutant en C# va terminer avant moi une interface graphique en c# si moi je la code en c++

Et je la finis en Delphi/C++ Builder largement avant le développeur C#... En Delphi, le code sera même plus robuste qu'en C#, voire peut-être même plus performant car le code est natif : est-ce un critère absolu de mérite ou de "puissance" ?

WPF est dédié à remplacer les MFC, et franchement, ce n'est pas un mal (ça en avait besoin)... Toutefois, c'est encore loin de la puissance de RAD comme Delphi, qui ont leur contrepartie aussi : même si c'est parfois difficilement mesurable, ils sont un peu plus lents que du C++/MFC, et s'interfaçent un peu moins bien avec le système d'exploitation et les DLL C++.

Encore une fois, cela dépend de tes besoins, et ces besoins conditionnent le choix de la plate-forme, du langage et des frameworks à utiliser. C++ n'est pas adapté à tout, et ce n'est pas un problème de conception que de ne pas l'utiliser dans un domaine où il n'est pas très adéquat... Et le domaine où il l'est particulièrement requiert, justement, de parfois péter les conceptions type framework au profit d'un code plus efficace.

Tu apprends aussi parfois à revoir tes conceptions "haut niveau" pour avoir des choses tout aussi modulaires et souples, mais adaptées au bas niveau... Cela demande à savoir où s'arrêter dans la généricité, et à savoir où poser les couches d'abstraction pour permettre la modularité du code sans plomber les performances. C'est tout un art, qui s'apprend sur le tas à force de se planter en faisant soit des usines à gaz poussives, soit du code "en dur" inmaintenable et non évolutif...

[Invité]

Encapsuler une bibliothèque A dans une couche présentant l'API de la bibliothèque B afin de pouvoir facilement intervertir les deux bibliothèques (ou plus généralement présenter une API unique pour plusieurs implémentations différentes).

N'est ce pas, suivant l'objectif, soit le pattern adaptateur, soit le pattern pont? Ceux là sont tournés "vers le bas", servant à isoler les particularités d'API des bibliothèques de bas niveau (A et B).

J'ai l'impression que façade, dans l'esprit de ses inventeurs, proposait autre chose, je cite "fournir une interface unifiée à l'ensemble des interfaces d'un sous système".

Encapsuler une API bas niveau dans une API de plus haut niveau, probablement plus simple à utiliser (peut-être est-ce ce que tu entends par "l'API d'une librairie tierce est une façade").

Oui, quelque part, c'est ce que font les wrappers de pas mal de framework, qui camouflent une API système parfois un peu velue sous quelques appels standards et simples. Mais là encore, je ne suis pas certain de comprendre la spécificité du pattern facade, par rapport à d'autres...

Et je la finis en Delphi/C++ Builder largement avant le développeur C#... En Delphi, le code sera même plus robuste qu'en C#, voire peut-être même plus performant car le code est natif : est-ce un critère absolu de mérite ou de "puissance" ?

Pas mieux! A mon avis le principal avantage de Builder et de Delphi sera moins la rapidité de l'interface produite (en interface, la machine passe son temps à attendre les réactions horriblement lentes de l'utilisateur, la vitesse est un détail), que la possibilité d'appeler des fonctions "bas niveau" (C ou C++ compilé) qui, elles, auront été optimisées...

Par exemple, même si la gestion d'un glisser déplacer est lente, on va pouvoir lui affecter, très naturellement, un recalcul en C extrèmement rapide.

Actuellement, j'ai l'impression que C# ne fait pas le poids (trop lent encore), ni MFC (trop complexe à manipuler, pas assez haut niveau). Pour Qt je ne sais pas, si quelqu'un peut en parler, je suis preneur...

Francois

[gl]

N'est ce pas, suivant l'objectif, soit le pattern adaptateur, soit le pattern pont? Ceux là sont tournés "vers le bas", servant à isoler les particularités d'API des bibliothèques de bas niveau (A et B).

J'ai l'impression que façade, dans l'esprit de ses inventeurs, proposait autre chose, je cite "fournir une interface unifiée à l'ensemble des interfaces d'un sous système".

Ça tient effectivement peut-être plus de l'adaptateur.
Cependant la frontière entre les deux, au moins dans mon esprit, n'est pas forcément très nette et réside essentiellement dans l'intention.

[Invité]

Cependant la frontière entre les deux, au moins dans mon esprit, n'est pas forcément très nette et réside essentiellement dans l'intention.

C'est exactement ce qui me travaille depuis que j'ai lu le livre du Gang of Four...

Les pattern design partent d'un bon sentiment, et certains (le composite, le proxy) sont tout à fait bien vus. D'autres comme tous ces "adaptateurs" semblent des variations autour d'un même thème, pas finis...

Francois

[gl]

C'est exactement ce qui me travaille depuis que j'ai lu le livre du Gang of Four...

Les pattern design partent d'un bon sentiment, et certains (le composite, le proxy) sont tout à fait bien vus. D'autres comme tous ces "adaptateurs" semblent des variations autour d'un même thème, pas finis...

A mon avis, il y a deux grandes familles de design pattern où les frontières entre éléments de la famille sont assez floues :

• La famille façade/adaptateur/pont
• La famille fabrique abstraite/fabrication

[loufoque]

D'un autre côté, C++ reste un langage de bas niveau, même s'il est assez haut par rapport aux autres langages bas niveau...

C++ est un langage bas niveau, mais qui dispose de fonctionnalités d'abstraction qui permettent d'en faire un environnement de programmation aussi haut-niveau qu'on le désire.

[Issam_Lahlali]

Normalement, l'API d'une librairie tierce est une façade, devoir en ajouter une par dessus indique soit qu'il vaudrait mieux changer de librairie, soit que les utilisateurs l'emploient mal...

Je n'ai probablement rien compris, mais j'ai souvent l'impression que le pattern façade est une supercherie... Soit les fonctions utilisées par la façade sont bien faites, et la façade est inutile, soit elle sont inadaptées, et la facade est un cache misère...

Francois

Il y a plusieurs cas ou on peut faire une abstraction a une librairie:

- Librairie très performante mais non intuitive au niveau de l'utilisation, et j'ai l'impression que la majorité des librairies C++ ne sont pas intuitives

- Librairie trop générique et se caracterise par un niveau trés bas de granularité au niveau methodes, cad qu'au lieu d'appeller une methode pour faire le travail on est obligé d'appeller une sequence de methodes a chaque fois, et dans ce cas le mieux est de faire l'abstraction pour eviter les copier/coller.

- Librairie qu'on identifie au départ comme librairie a risque dans le sens ou elle peut pénaliser les perfs, par exemple si un projet fait bcp de XSL sur des XML volumineux il est fort recommandé de passer par une abstraction pour pouvoir facilement changer la librairie sans trop impacter le projet.

- dans le cas d'utilisation de librairie ou techno trop intrusif par exemple dans le cas de COM ou dans la majorité des projets utilisant COM on trouve les types COM qui trainent dans tout le projet.

[Mac LAK]

C++ est un langage bas niveau, mais qui dispose de fonctionnalités d'abstraction qui permettent d'en faire un environnement de programmation aussi haut-niveau qu'on le désire.

Heu... Il est "léger" à ce sujet par rapport à d'autres langages nettement plus haut niveau que lui, tu sais ? C++ possède surtout l'avantage d'être le plus haut des langages bas niveau (ou le plus bas des langages "haut niveau" si tu préfères), mais cela ne veut pas dire qu'il soit parfait à tous les étages !

Delphi l'enterre déjà rapidement rien qu'avec ses propriétés côté haut niveau, et ça reste un langage "comparable" en terme de génération. Ada permet des choses au moins aussi abstraites si ce n'est plus, et est très largement plus fiable en terme de code produit, et là encore on est dans un langage de la même génération et du même type.

Si on commence à taper dans les langages de très haut niveau, notamment fonctionnels et/ou formels, C++ ne tient plus la route côté temps de développement ou niveau d'abstraction : il n'y a plus QUE en terme de performances qu'il se défend.

Alors ces perfs peuvent être bien entendu une demande cruciale du développement, et donc imposer le C++ comme unique choix ou presque, mais vu les questions générales soulevées dans le topic, ça m'étonnerait quand même pas mal que ce soit le cas...

[Invité]

- Librairie très performante mais non intuitive au niveau de l'utilisation, et j'ai l'impression que la majorité des librairies C++ ne sont pas intuitives

Là, je suis assez opposé à l'idée de fabriquer une abstraction... D'abord, "intuitif" cest vraiment une question de culture, des choses intuitives pour moi ne le seront pas pour toi.

Ensuite, si le problème est le vocabulaire de la librairie, on est typiquement dans le domaine d'application du préprocesseur. Mais bon, une librairie performante que les utilisateurs ont du mal à utiliser, cela dénote un problème, soit au niveau de la librairie soit à celui des utilisateurs....

Mais dans ce cas, je découragerais une facade, qui ajouterait du code qui ne sert qu'à simplifier la vie du programmeur.

- Librairie trop générique et se caracterise par un niveau trés bas de granularité au niveau methodes, cad qu'au lieu d'appeller une methode pour faire le travail on est obligé d'appeller une sequence de methodes a chaque fois, et dans ce cas le mieux est de faire l'abstraction pour eviter les copier/coller.

Je suis d'accord sur ce point, même si je pense qu'il s'agit davantage de créer une interface à la librairie que de faire une facade dans l'application. Enfin, bon...

- Librairie qu'on identifie au départ comme librairie a risque dans le sens ou elle peut pénaliser les perfs, par exemple si un projet fait bcp de XSL sur des XML volumineux il est fort recommandé de passer par une abstraction pour pouvoir facilement changer la librairie sans trop impacter le projet.

Ca, c'est typiquement le cas où l'on utilise un adaptateur ou un pont... Ceci dit, j'avoue avoir du mal à comprendre. Une librairie identifiée comme "à risque", c'est la première chose qu'on va tester, non? Et là c'est simple: soit ca passe, et le problème ne se pose pas, soit ca ne passe pas, et le problème ne se pose pas non plus...

- dans le cas d'utilisation de librairie ou techno trop intrusif par exemple dans le cas de COM ou dans la majorité des projets utilisant COM on trouve les types COM qui trainent dans tout le projet.

Sur celui là, je ne vois pas le rapport.

Francois

[Issam_Lahlali]

Ca, c'est typiquement le cas où l'on utilise un adaptateur ou un pont... Ceci dit, j'avoue avoir du mal à comprendre. Une librairie identifiée comme "à risque", c'est la première chose qu'on va tester, non? Et là c'est simple: soit ca passe, et le problème ne se pose pas, soit ca ne passe pas, et le problème ne se pose pas non plus...

il y a des cas ou on ne peut pas avoir le vrai environnement de production dés le départ ou l'interaction entre modules peut nous sortir des surprises.
au départ on ne peut tester que d'une manière isolé mais qui t'assure qu'a l'intégration finale on a pas des surprises.

Sur celui là, je ne vois pas le rapport.

c'est le cas ou on utilise une librairie sous forme de composants COM, le mieux est de cacher la logique COM pour simplifier l'utilisation, et dans le monde microsoft on utilise beaucoup des librairies composés de composants COM que je trouve intéressante d'ailleurs comme techno, d'ailleurs le monde unix ont eu du mal a proposer une techno similaire qui dépasse les frontières du langage et propose des composants binaire mais bon c'est un autre sujet ou il faut un topic specifique .

[loufoque]

Heu... Il est "léger" à ce sujet par rapport à d'autres langages nettement plus haut niveau que lui, tu sais ?

Comme je l'ai dit, C++ peut être aussi haut niveau qu'on le souhaite, la preuve étant qu'on peut créer n'importe quel langage de domaine spécifique embarqué au sein de C++ grâce à la technique des expression templates, qui définissent alors un AST sous la forme d'un type, qu'on peut ensuite évaluer comme on veut avec de la méta-programmation.

L'association du bas-niveau et des fonctionnalités de création aussi haut-niveau qu'on le veut, c'est ça qui en fait l'un des langages les plus intéressants.

[Alp]

Comme je l'ai dit, C++ peut être aussi haut niveau qu'on le souhaite, la preuve étant qu'on peut créer n'importe quel langage de domaine spécifique embarqué au sein de C++ grâce à la technique des expression templates, qui définissent alors un AST sous la forme d'un type, qu'on peut ensuite évaluer comme on veut avec de la méta-programmation.

L'association du bas-niveau et des fonctionnalités de création aussi haut-niveau qu'on le veut, c'est ça qui en fait l'un des langages les plus intéressants.

Tout à fait. J'ai toujours été fasciné par cet aspect là du C++ d'ailleurs. Ca ne vaut pas Haskell ou autre, mais on est quand même bien content de pouvoir faire un DSEL qui va générer le code à notre place, facilitant énormément les choses pour le développeur qui se sert de notre code.

[Matthieu Brucher]

A mon avis, il y a deux grandes familles de design pattern où les frontières entre éléments de la famille sont assez floues :

• La famille façade/adaptateur/pont
• La famille fabrique abstraite/fabrication

Dans le GoF, ils sont séparés en 3 grandes catégories, selon ce qu'ils font. Adapteur et façade sont proches, mais l'un travaille sur une classe, l'autre travaille sur plusieurs classes.

[Matthieu Brucher]

il y a des cas ou on ne peut pas avoir le vrai environnement de production dés le départ ou l'interaction entre modules peut nous sortir des surprises.
au départ on ne peut tester que d'une manière isolé mais qui t'assure qu'a l'intégration finale on a pas des surprises.

C'est pour ça que les tests de performances doivent être envisagés dès le début sur des jeux de données réalistes. On fait ça pour tous les projets où c'est critique.

[Luc Hermitte]

Delphi l'enterre déjà rapidement rien qu'avec ses propriétés côté haut niveau, et ça reste un langage "comparable" en terme de génération.

Et C++ enterre Delphi côté généricité ou autres artéfacts comme boost.unit.
Le niveau ne va pas dans un seul axe haut bas. C'est révolu depuis bien longtemps cette dichotomie.

[Mac LAK]

Comme je l'ai dit, C++ peut être aussi haut niveau qu'on le souhaite, la preuve étant qu'on peut créer n'importe quel langage de domaine spécifique embarqué au sein de C++ grâce à la technique des expression templates, qui définissent alors un AST sous la forme d'un type, qu'on peut ensuite évaluer comme on veut avec de la méta-programmation.

OK, mais il est très loin des langages fonctionnels à ce niveau, les templates complexes rendent le code absolument intraçable en cas de bug, et C++ n'est pas le seul langage à permettre ce genre de chose (cf. Ada et ses packages par exemple).

Les templates, c'est bien joli et tout et tout, mais quand tu te retrouves avec des dizaines de templates imbriqués entre eux et que tu as une boulette dedans, en général, t'es nettement moins convaincu. C'est exactement comme les macros en C : cela permet des choses extrêmement puissantes, mais en abuser est rarement une excellente idée côté maintenabilité du code.

Pour ma part, côté génération de code C++, je passe par un métalangage plutôt que par des templates... Nettement plus maintenable à long terme.

L'association du bas-niveau et des fonctionnalités de création aussi haut-niveau qu'on le veut, c'est ça qui en fait l'un des langages les plus intéressants.

Bien que n'étant pas du tout fan de ces langages, j'ai au moins l'honnêteté de reconnaître que cela reste ridicule par rapport à de vrais langages de haut niveau comme ML, Haskell, Lisp, etc. qui sont, eux, taillés "exprès pour".

Comme je disais dans mon premier message, "on peut actuellement presque tout faire avec presque tous les langages, mais certains choix sont au mieux malheureux, au pire stupides.".
Je ne dénigre pas le C++ en tant que tel, attention, j'en bouffe au quotidien. Mais il faut arrêter de croire qu'il existe un "langage-panacée-adapté-à-tout" : chaque langage possède un domaine où il explose les autres, et le C++ n'est pas en tête de podium partout.

Par contre, il l'est dans le bas niveau, notamment et surtout le bas niveau juste au dessus de la machine, avant d'arriver aux éléments "humains" (IHM) ou trop haut niveau. Mais plus tu "montes" dans le niveau de conception, et plus tu vas entrer en concurrence avec des langages comme C#, Java, Python pour le côté framework / modularité, ou Haskell, ML, Caml pour le côté généricité / abstraction.
Et, encore une fois, en fonction de ce que tu fais et du projet en cours, C++ n'en sort pas vainqueur.
Côté points forts, par contre, C++ est difficilement détrônable au bas niveau (il n'y a guère que le C et l'ASM à pouvoir rivaliser), tout en permettant une abstraction relativement élevée. Or, la conception à ce niveau de développement n'a pas grand-chose à voir avec la conception basée sur frameworks et librairies tierces à outrance, d'où l'impression d'être focalisé sur la technique plutôt que la conception pour quelqu'un qui arrive du "haut niveau".

Et n'oublions pas qu'il ne pourrait pas y avoir de programmes de haut niveau avec des performances correctes s'ils ne tournaient pas sur un bas niveau réellement performant, ce qui explique aussi pourquoi le C/C++ ne dégringolent pas réellement dans la liste des langages les plus utilisés.

Mais, encore une fois, ça ne veut pas dire qu'ils sont adaptés à faire tout et n'importe quoi : à partir d'un moment, la complexité du code est trop grande (ou les temps de compilation trop longs) pour envisager la moindre maintenance, si l'on "exagère" en poussant le langage trop loin...

[MenshaKaine]

Bonjour,

je suis très intéressé par votre discutions.

Je suis actuellement développeurs C++ en société de service et j'ai à mon actif plusieurs projet développer en C-- et quelques un en C++. Et j'avoue que j'en ai était fort déçut jusqu'à me demander s'il y avait un avenir dans ce langage !

Mon analyse est la suivante. La plupart des développeurs que j'ai croisé dans le monde du service étaient pour la grande partie soit des débutant ayant une formation très faible en C++ c'est à dire une connaissance du C et quelques Geeks très difficile à gérer et peu pédagogue !

Si on revient au contenue des projets, que dire ... :
- J'ai du expliqué trop souvent l'intérêt de placer en "protected" ou "private" les attributs d'une classe.
- J'ai vu souvent des "memcpy" à la place du constructeur par copie.
- j'ai vu des gens cracher sur la STL et préférer le tableau natif ...
- j'ai vu des gens hurler devant l'usage de template !
- j'ai vu des gens proposer des implémentation assembleur pour gagner en vitesse sur la conversion de type du C++ qui avait été vendu plus rapide que du VB et qui donnait des performances moindre !
etc etc ...

et de toute façon ce qui intéressait les chefs c'est que le projet soit livrable en temps et en heure !

Les 2 seuls expériences qui m'ont fait vraiment adorer ce langage que je trouve extrêmement intéressant ont eu lieu soit chez un éditeur de logiciel soucieux de la qualité du code avec une équipe expérimenté et un projet qui commençait avec une équipe de jeune développeur très motivé par la conception et le C++.

Pour moi le C++ parait trop un langage pour une élite ou des geeks ce qui rebute la plupart de mes collègues ! il faut investir beaucoup de temps personnel pour acquérir un niveau correcte, faire des efforts pour trouver des sources d'information dispersé et souvent ardu à appréhender seul ...

Alors la question est pour moi:
dois-je faire comme mes collègues et me diriger vers des langages qui semble prendre de plus en plus de part de marcher ou continuer a subir une majorité de projet médiocre dans notre cher langage ?!

[white_tentacle]

dois-je faire comme mes collègues et me diriger vers des langages qui semble prendre de plus en plus de part de marcher ou continuer a subir une majorité de projet médiocre dans notre cher langage ?!

Tu dois t'intéresser aux autres langages, clairement. Pour deux raisons :
- une connaissance généraliste est toujours un plus, il y a du bon et du moins bon dans tous les langages, en connaître un de plus est toujours une bonne expérience
- ça t'offrira plus d'opportunités, et quand il faut manger c'est toujours bon à prendre .

Pour le reste, c'est avant tout une question de plaisir que toi tu y prends. Si tu prends plus de plaisir à faire des projets en c++ médiocre qu'en c# médiocre, la réponse est assez claire...

[Issam_Lahlali]

C'est pour ça que les tests de performances doivent être envisagés dès le début sur des jeux de données réalistes. On fait ça pour tous les projets où c'est critique.

c'est vrai si on maitrise tout dés le depart et on sait exactement ce qui est demandais et ca ne changera jamais par le client, mais encore une fois ca n'existe que dans un monde ideale.

dans un monde réel on peut avoir des changements dans les specs a tout moment même a la fin du dev

c'est pour cela qu'il faut se protéger par le couplage faible si on juge utile,pour s'adapter aux changements d'une manière souple et flexible, un projet fortement couplé avec les librairies techniques est un projet rigide qui ne tolère pas les changements des specs chose qu'on a quasiment tout le temps dans notre métier

en tout cas en ce qui me concerne dans les projets ou j'ai assistés , pour N raison a un moment il fallait soit changer de librairie, soit proposer une alternative parce que le client voulait utiliser une librairie payante mais performante, donc on peut avoir plusieurs librairies techniques pour le même besoin.

c'est pour cela que suis pour un couplage faible avec les librairies techniques, dans la réalité ça sert toujours mais effectivement c'est pas obligatoire dans les conditions idéales.