Discussion :

[koala01]

J'ai une big objection sur cette remarque. Non, sans rire, sous entendre qu'il puisse y avoir une distinction entre le pattern Observer et boost.signals relève de l'hérésie. Pour vulgariser, ce pattern ne fait jamais qu'expliquer la réalisation d'un système d'évènements, et boost.signals est très exactement fait pour simplifier la réalisation de ce genre de système. Le look "fonctionnel" (utilisation de foncteurs, simple facilité syntaxique du langage) de cette biblio n'affecte en rien son potentiel.

Un pattern c'est un concept, au meme titre que celui des boucles, des tests, des piles, files, listes chainées et autres arbres binaires.

Le principe est toujours le même: connais le concept et comprend le pour pouvoir l'adapter à tes besoins.

Une fois que tu as une "maitrise" suffisante du concept, que tu es capable de reconnaitre dans une phrase utilisant des mots de tous les jours que tu es face à ce concept, et que tu peux avoir une idée précise( bien que peut être incomplète) de la manière dont tu l'implémenterais si tu devais le faire toi-même, il est toujours temps de commencer à envisager la question de savoir s'il n'existe aucune implémentation "sécurisante" pour te faciliter la vie et pour t'éviter d'avoir à réinventer la roue.

En sachant cela ça se résume, à mon sens, à inclure ou pas une biblio externe. (Je ne suis pas d'accord avec toi koala, taper du code uniquement pour s'entrainer sur un concept théorique est une chose, mais utiliser ce code dans un programme en est une autre - quand bien même ce serait un exercice à rendre au prof).

Non, et non...

D'abord parce que toute librairie n'a un intérêt que dans le sens où les gens sont capables de se rendre compte du fait qu'ils en ont besoin pour le problème face auquel ils sont...

Si tu dis simplement à une personne "utilise cette librairie" sans lui expliquer pourquoi l'utiliser ou quel concept elle met en oeuvre, c'est comme de donner un poisson à quelqu'un: il l'utilisera un jour.

Si, par contre, tu lui permet de comprendre le concept sous-jascent et les cas dans lesquels le concept sera utile, cela revient à apprendre à quelqu'un à pêcher et à lui donner le matériel pour le faire: il s'en servira toute sa vie.

De plus, comme je l'ai déjà expliqué plus haut, une bibliothèque n'a réellement de sens que quand la personne qui l'utilise a appris à l'utiliser, entre autres, en apprenant la syntaxe et les noms de classes / de fonctions qu'elle présente.

Or, même s'il n'y a que finalement peu de fichiers contenant autre chose que des directives pré-processeur dans Boost Signals, arriver à comprendre le fonctionnement de cette bibliothèque particulière nécessite quand même d'être un minimum à l'aise avec les template, la logique du concept implémenté et la langue de shakespeare, ce qui n'est pas *forcément* donné à tout le monde.

Au final, avant d'être en mesure de l'utiliser correctement, l'investissement en temps peut s'avérer réellement fort important si ce n'est que pour utiliser le concept que de manière ponctuelle, bien que tous puissent être convaincus que le ROI sera important et rapide.

Un pattern est un pattern, c'est à dire un modèle de conception. Donc quelque chose d'abstrait.
boost.Signals est une implémentation du pattern Observer, rudement bien écrite, certes, mais ne va pas éclairer un débutant sur la vrai façon de programmer un design pattern observer.
Observer et comprendre fondamentalement un pattern, c'est autre chose que faire un #include <boost/signals> et faire un copier coller d'un tutorial... Quand on a vraiment compris quelque chose, c'est pour longtemps. Appliquer une solution à un problème que l'on a pas pris le temps de comprendre, c'est se reposer les mêmes questions 6 mois après quand le même problème se posera...
Pédagogiquement, je suis "pour" comprendre en faisant.

Après, une fois de plus, quand le pattern est bien compris (d'après les posts du demandeur ici présent ce n'est pas le cas), je suggère comme Koala d'utiliser les libs qui "marchent". Et boost en fait parti...

+10000

[HanLee]

Il y a des patterns, ok, c'est bien d'un point de vue architecture logiciel.

Mais il y a des patterns comme Observer dont la formalisation relève un peu de la masturbation intellectuelle !

Ca vient quand même du fait que les langages classiques étaient peu expressifs au niveau de leur typage, et pêchaient surtout en programmation fonctionnelle.

Si tous les langages possédaient un type fonction naturel, il n'y aurait jamais eu besoin de toute cette machinerie alambiquée pour expliquer comment réaliser un tel mécanisme.
On l'aurait peut-être formalisée, mais de manière idiomatique à l'aide de [boost|std]::function, et je considère Boost.Signals comme une surcouche de Function.

C'est un peu comme si quelqu'un me montrait à quel point il manipule comme un artiste une liste d'entiers.

D'autres exemples : le pattern Strategy, Command assez inutiles avec [boost|std]::function.

----------

Un autre exemple, c'est quand on abuse du pattern Composite quand on peut pas créer des types algébriques ou bien des types récursifs facilement.
Bam, là on abusera de l'héritage, et on doit se taper de la gestion de la mémoire.

Heureusement, on peut améliorer ça avec Boost.Variant.

[koala01]

Il y a des patterns, ok, c'est bien d'un point de vue architecture logiciel.

Mais il y a des patterns comme Observer dont la formalisation relève un peu de la masturbation intellectuelle !

Non cela releve d'un fait acquis lors de l'étude du GoF: Des générations de programmeurs l'utilisaient sans le savoir (et surtout sans le nommer) à chaque fois qu'ils en avaient besoin, et le plus souvent, en réinventant systématiquement la roue, et en se posant systématiquement la question de savoir comment arriver à l'implémenter

Ca vient quand même du fait que les langages classiques étaient peu expressifs au niveau de leur typage, et pêchaient surtout en programmation fonctionnelle.

Là dessus, nous sommes d'accord... Mais il faut bien faire avec ce que l'on a...

Finalement, quand tu regarde la plupart des langages de programmation existant et ayant un "minimum" d'utilisateur, il faut admettre que ceux qui supporte la programmation fonctionnelle sont relativement en minorité ... Encore une fois, il faut faire avec ce que l'on as

Si tous les langages possédaient un type fonction naturel, il n'y aurait jamais eu besoin de toute cette machinerie alambiquée pour expliquer comment réaliser un tel mécanisme.

On l'aurait peut-être formalisée, mais de manière idiomatique à l'aide de [boost|std]::function, et je considère Boost.Signals comme une surcouche de Function.

Mais, comme avec des "si" on met Paris en bouteille...

Le monde idéal, en programmation comme dans la vie de tous les jours, ce n'est pas encore pour demain... Et sans doute pas encore pour ce siècle

D'autres exemples : le pattern Strategy, Command assez inutiles avec [boost|std]::function.

Un autre exemple, c'est quand on abuse du pattern Composite quand on peut pas créer des types algébriques ou bien des types récursifs facilement.
Bam, là on abusera de l'héritage, et on doit se taper de la gestion de la mémoire.

Heureusement, on peut améliorer ça avec Boost.Variant.

Encore une fois, tous tes exemples sont l'implémentation de quelque chose qui a su être "formalisé" ...

Il ne faut pas mettre la charrue avant les boeufs: il est rare de trouver la solution à un problème si l'on n'a pas encore cerné le problème auquel on est confronté

Si tu pars dans ce sens, tu va finir par nous dire que les concepts de pile, file, liste et autres arbres binaires, voir FIFO ou LIFO sont inutile du fait de l'existence des class stack, queue, list et autre pair, set ou map

Et pourtant, si tu n'est pas en mesure de déterminer que tu va devoir effectuer une gestion FIFO de tes données, tu auras du mal à décider d'utiliser std::queue

Par pitié...

Je suis pour le fait de donner directement les bonnes habitudes aux "débutants", mais il n'en demeure pas moins que, quand ils ignorent l'existence d'un concept (et je place les DP's dans la catégorie concept), commençons par leur donner la possibilité de s'approprier le concept avant de les lancer, seuls à eux même, dans l'utilisation d'une classe ou d'une bibliothèque dont ils ignorent tout.

Ceci n'empêchant nullement d'introduire très rapidement "la classe qui va bien", ni de les inciter à l'utiliser... Mais, qu'au moins, ils sachent... pourquoi ils l'utilisent

[HanLee]

Si tu pars dans ce sens, tu va finir par nous dire que les concepts de pile, file, liste et autres arbres binaires, voir FIFO ou LIFO sont inutile du fait de l'existence des class stack, queue, list et autre pair, set ou map

Ah, je vois je me suis mal exprimé.
Ce que je critiquais, c'était la manière de toujours présenter l'implémentation du pattern Observer à la manière de Wikipédia.

En C++, on apprend les fonctions. Alors utiliser le pattern Observer, ça revient à maintenir une liste de fonctions, et d'itérer sur la liste pour appeler toutes les fonctions à chaque fois qu'il faut notifier d'un événement.
Présenter le concept comme ceci est bien plus générique et plus souple que la façon classique.

Avec l'exemple classique, on était obligé d'hériter d'une classe commune pour pouvoir être notifié.
En plus, c'est bien trop compliqué de présenter un concept comme ça !
Ils auraient simplement dû dire que c'était un moyen d'implémenter ce pattern si on ne pouvait pas faire autrement.

Presque tous les langages ont des fonctions, et pourtant, rien dans UML n'interdisait d'utiliser un type fonctionnel.
Dans UML, on voit bien des diagrammes avec des membres de type int, float, string. Il aurait suffit de mettre un membre de type fonction (void -> void) par exemple.

C'est comme ça (à isomorphisme près) qu'aurait du être présenté le pattern Observer, et il aurait perdu toute sa pseudo-magie, relégué au même rang que LIFO/FIFO.

Je suis d'accord sinon pour le reste.

Encore une fois, tous tes exemples sont l'implémentation de quelque chose qui a su être "formalisé" ...

Une commande ~ fonction (sens C/C++) ~ procédure, tout ça mis à la sauce objet pour faire style, sans aucun apport.
Pareil pour Strategy.

Est-ce qu'il y a eu besoin d'apprendre ces patterns pour comprendre un std::for_each(), std::sort(), std::find_if() ?
Je pense que tu seras d'accord avec moi que LE concept central dans ces cas particuliers, c'était la fonction (et ses cas particuliers comme le prédicat) !

Pédagogiquement, tout est bien plus simple comme ça.

[loufoque]

En programmation orientée objet pure, il n'y a pas de types pour les fonctions, c'est pour ça que le pattern observer prend des Observers.