Différence avec le pattern Stratégie ?

Bonjour à tous et toutes,


A mon sens, le Pattern pont (bridge) et Stratégie sont très proches est difficile(pour moi) à différencier.

Donc voilà j'ai essayé d'imaginer 2 exemples utilisant le pattern bridge, enfin j'espère qu'il s'agit bien du pattern bridge justement!?

Et j'aimerais bien avoir votre avis, c-à-d savoir si pour vous oui ou non
un pattern bridge est mis en jeu dans ces exemples, et si non, pourquoi et
quel pattern voyez-vous alors?


Merci beaucoup de votre participation et votre aide.

Exemple1 (Pièce jointe)

Ce qui aurait pu être fait si pas utilisation de pattern:

Autre exemple donc:

Désolé, je me suis trompé sur ce le diagramme précédent , j'ai écrit
#oCodeImplementor au lieu de #oSynaxImplementor !! ;)

Sinon voici je que consudèrerai comme "anti-pattern" de cet exemple 2:

Le pattern Bridge (Pont) permet de découpler une abstraction de son implémentation ; il s'agit d'un pattern struturel.
Généralement, lorsqu'on implémente une abstraction, on "hérite" d'une classe la représentant (en Java, ce serait plutôt une interface). Mais cela couple fortement l'implémentation et l'abstraction, qui ne peuvent varier indépendamment l'un de l'autre, et cela peut ne pas être souhaitable.

Le pattern Strategy (Stratégie) lui, est un pattern comportemental. Il définit une famille d'algorithmes interchangeables. Suivant la stratégie choisie, l'objet se comportera différemment.

Dans ton cas, le deuxième exemple, est un exemple de pont : tu découples l'abstraction de boucleFor de son implémentation (boucleForJava, boucleForCSharp).
Le premier ressemble n'est pas un pont. Theme ne correspond pas à l'abstraction de vueHTML. Ce n'est pas réellement une stratégie, à moins que je n'ai pas compris à quoi sert cette classe ;)

Merci pour ta réponse Patriarch24.

Donc d'après toi, le second exemple est un PATTERN BRIDGE, quant au premier non.

Très bien, je suis content que tu me confirmes qu'il s'agit d'un PONT pour le 2eme, ça me conforte.
Quant au premier exemple, tu as certainement raison, mais j'ai encore un doute.

En fait, dans le premier exemple je veux dire que:

Une classe Theme CONCRETE définit un style de la façon suivante, par exemple:
- Elle dit: tous les tags HTML <input> bénéficieront du style: "background-color: black; color: purple"
-Tous les tags HTML <div>, du style: "border-style: double; font-style: italic"
- et éventuellement etc...

Chacune de ces classes THEME CONCRET, est bien sûr paramétrable, à savoir qu'on pourra dynamiquement modifier le nom des tags impliqués ainsi que leur style.

1 OBJET THEME CONCRET <=> 1 jeu de style, 1 DESCRIPTION DE STYLES disponible pour page HTML. Donc 1 OBJET THEME CONCRET <=> à une façon, une implémentation pour la déco. d'une page HTML.

Je souhaite également que toute page HTML se voit OBLIGATOIREMENT attribuer un des THEMES CONCRETS disponible sans quoi elle ne serait pas affichable par exemple.
Ainsi dans mon exemple "la page HTML" d'accueil ne serait rien sans sa déco.", elle serait comme abstraite, incomplètement définie, et ce serait la déco., le THEME CONCRET qui lui permettrait de se réaliser VISUELLEMENT.
Bon je sais c'est un peu tirer par les...

Du coup si la déco. réalise la VIABILITé de la page HTML, sans le pattern présenté , on aurait un truc comme celui du diagramme "anti-pattern" de l'exemple1, à savoir pour la classe pageHTML_DAccueil:
-une sous-classe pageHTML_DAccueil_THEME1 pour la version de pageHTML_DAccueil stylée par le THEME1,
-une sous-classe pageHTML_DAccueil_THEME2, pour la version de pageHTML_DAccueil stylée par le THEME2, etc...

Et pareil pour la classe autrePageHTML...


Est-ce que c'est plus clair ?? :)
Aussi loufoque que puissent paraître les contraintes, reniflerais-tu un semblant de pattern PONT?

Merci à toi.

Merci hegros ci-dessous :mouarf:
Ca y est j'ai modifié mon erreur de saisie... ;)

Citation:

---

Envoyé par rp37000

ERRATUM: en fin du message précédent , après "Merci à toi" il subsiste des lignes dont ne pas tenir compte ;) désolé!

---

Tu peux éditer ton message ;)

Citation:

---

1 OBJET THEME CONCRET <=> 1 jeu de style, 1 DESCRIPTION DE STYLES disponible pour page HTML. Donc 1 OBJET THEME CONCRET <=> à une façon, une implémentation pour la déco. d'une page HTML.

Je souhaite également que toute page HTML se voit OBLIGATOIREMENT attribuer un des THEMES CONCRETS disponible sans quoi elle ne serait pas affichable par exemple.

---

Dans ce cas, il ne s'agit pas d'un pont plus d'une stratégie. Ce qu'il faut bien comprendre avec les design patterns, c'est qu'il ne s'agit pas que de structures (diagrammes de classes statiques), mais de définitions avec un contexte et un but. Dans ce cas-là, tu cherches à afficher différemment les pages html en fonction du thème choisi : si c'est l'objet thème qui est responsable du rendu (ce qui ne devrait, à mon avis, pas être le cas) alors il s'agit d'une stratégie car thème définit alors l'algorithme d'affichage, ce qui correspond bien au pattern Strategy.

Dans ton cas, si je suis bien d'accord qu'une "vue Html" peut détenir un thème, je pense que le rendu ne devrait pas être effectué par l'objet thème lui-même, mais par un tiers dont la responsabilité est justement de faire le rendu d'une vue html en fonction de son style (HtmlRenderer par exemple) ; dans ce cas, il n'y a plus vraiment de pattern ici.

Tu as de quoi creuser maintenant, bon courage.

Merci Patriarch24,

Je prends en compte tes remarques.

;)
:king:

MERCI à toi et à tous.

Voici un EXCELLENT exemple pour mettre en évidence l'intérêt du pattern bridge.


http://sourcemaking.com/design_patterns/bridge