Discussion :

[bilux]

Bonjour,
la transposition des patrons de conception est-elle identique sur Java et C++ ?

Merci

[Davidbrcz]

Je ne suis pas un pro en java, mais en googlant 2 seconde, je peux dire que non.

[bilux]

oui, mais quel est la différence ?

[metagoto]

S'il s'agit des patrons du GOF, pardon, GOF, alors il faut savoir qu'ils ont été implémentés en c++ à l'origine (et smalltalk).
Donc ça devrait le faire, même si forcément, ça a plus de "gueule" en c++
Un lien intéressant:
http://www.vincehuston.org/dp/

[Alp]

En C++, ça peut aller jusqu'à ressembler à ce qu'a fait Andrei Alexandrescu avec Loki, par exemple : http://loki-lib.sourceforge.net/inde...n=Main.Pattern

En gros, on fait bénéficier l'aspect OO des DP de la programmation générique.

[JolyLoic]

Ça va même bien plus loin... Par exemple, le pattern observer, je l'implémenterais non pas avec une classe de base, mais avec un système de type boost.signal.

[Alp]

Ça va même bien plus loin... Par exemple, le pattern observer, je l'implémenterais non pas avec une classe de base, mais avec un système de type boost.signal.

Tout à fait. C'est d'ailleurs ce à quoi correspond, grossièrement, boost.signal.

[Luc Hermitte]

Et boost::/std::tr1/std::function pour le pattern commande.

Les patterns sont aussi des solutions clé en main pour résoudre des problèmes que les langages/paradigmes ne savent pas faire naturellement.

[koala01]

Salut, et bienvenue sur le forum.

Les patrons de conceptions ont, à la base, été énoncés parce que l'on a remarqué que nous sommes confrontés à des problèmes "récurrents" pour lesquels une solution à peu près similaire est souvent envisagée.

Le fait est que la manière d'implémenter ces solutions est fortement tributaires des restrictions propres à chaque langage.

Java est exclusivement un langage OO, et subit, entre autres, des restrictions sur l'héritage multiple, propres au fait que tout est référence ou à l'absence de pointeurs tels qu'on les connait en C++

De son coté, C++ est multi-paradigme (OO, séquentiel et générique), supporte l'héritage multiple et permet de créer des variables qui contiennent en réalité l'adresse à laquelle on trouve une donnée particulière (des pointeurs).

Et ce ne sont encore que les points qui viennent directement à l'esprit lorsque l'on décide de comparer C++ et java d'un point de vue technique

Il est donc tout à fait logique d'estimer que, dans leur implémentation "de base", on rencontrera souvent de légères variantes entre le java et le C++.

Et comme, en plus, il est possible d'ajouter, entre autre, une orientation utilisant le paradigme générique (les template, cf la bibliothèque loki déjà citée) à ces patrons de conception, il devient encore plus évident que l'implémentation peut être tout à fait différente en C++ qu'en java

Voire, même que tu doive, selon la granularité des comportements que tu souhaites mettre en oeuvre, faire un choix entre "un certain nombre" d'implémentations potentielles différentes.

Par contre, ce qui ne changera absolument pas, ce sont les cas dans lesquels tu décidera de choisir un patron de conception pour assumer un besoin déterminé

[Jean-Marc.Bourguet]

Ça va même bien plus loin... Par exemple, le pattern observer, je l'implémenterais non pas avec une classe de base, mais avec un système de type boost.signal.

Moi pas. Ou plutot, j'inverserai l'affirmation. Je me resoudrais a employer le pattern observeur a la place de qqch comme boost.signal si je n'en dispose pas. Les deux me semblent des solutions a des problemes proches mais differents.

(En passant, si on tient absolument a utiliser des termes francais, motif ou schema me semblent mieux que patron).