comment faire pour construire un [COMPOSITE]

Bonjour à tous et toutes,


J'ai bien compris l'intérêt du PATTERN BUILDER (MONTEUR) d'une part,
et d'autre part l'intérêt du PATTERN COMPOSITE.

Mais je cherche un exemple particulier d'utilisation dans lequel le BUILDER sert à créer un arbre .
Dans cette problématique là précisément, je me demande comment distribuer les rôles:

1- Quelles seraient les méthodes de la classe BUILDER Abstraite ?

2- En fonction de quoi le Directeur(celui qui invoque les méthodes de la classe BUILDER Abstraite), appelerait telle ou telle méthode de la classe BUILDER ABSTRAITE ?

3- D'un BUILDER CONCRET à l'autre , qu'est-ce qui varierait dans l'implémentation des méthodes héritées de la classe BUILDER Abstraite ?


Bon, par contre j'imagine bien que:
- le PRODUIT fini à fournir au Directeur est un objet ARBRE, un composite, récupérable par le Directeur par une méthode getArbre() de la classe BUILDER Abstraite.
- le CLIENT crée une instance de Directeur, et passe en param. à son constructeur une instance BUILDER.
Mais après... dans le cas de la création d'un arbre???


Mille merci pour votre aide.

Tu as des exemples sur dvp :
http://smeric.developpez.com/java/uml/monteur/
Le cas ne s'applique pas directement pour la construction d'un arbre, mais tu peux t'y retrouver :D
Sinon, à cette adresse tu as un petit tuto (j'ai pas tout lu) qui discute de la construction d'arbre : http://www.mactech.com/articles/mact...ternstutorial/.

Merci Patriarch24 pour ton intervention ,

En fait le premier lien que tu indiques, j'avais déjà yeuter vite fait, mais la démarche est trop lourde, en fait je cherche une réponse claire et rapide,
simple et efficace, un exemple minimaliste, simple et efficace, :mouarf:
(je suis difficile oui je sais...)
genre un exemple avec le diagramme de classe complet tout de suite où l'on voit de suite les méthodes du Directeur, et des BUILDERS, tjs dans le cas de la construction d'un arbre bien sûr.

Quant au second lien , pareil et en plus en anglais..., ça va pas assez droit au but pour moi, à savoir le diagramme (quelle classe fait quoi??)

J'veux pas faire ma fainiasse mais disons plutôt que je pensais que ce genre de problème à résoudre était bien connu des gourous et que la réalisation qu'un diagramme de classes en la matière était "automatique", azffaire courante,...!!
En fait c'est juste que je ne veux pas me palucher '30000 lignes' de baratins et de code pour avoir un semblant de réponse, et encore en arrivant au bout je suis pas sûr d'avoir réponse à mes questions.

J'espère que tu comprends.

Et Merci encore à toi pour ta présence et ton investissement.

J'ai encore regardé le premier lien: non c'est pas clair pour moi... ce qu'il raconte le gars :bug: :aie: :(

Allez, un autre alors :
http://www.industriallogic.com/xp/re...ithBulder.html.

C'est suffisamment simple pour que tu comprennes je pense !

Wouah!! Super Patriarch24!

MERCI BEAUCOUP! :king:

1- Les méthodes de la classe Builder sont donc :
- addChild(String child) et addToParent(String parent , String child)
Et l'objet Builder concret reçoit en param. de son constructeur une String
correspondant à la racine de l'arborescence, cette racine étant choisie par
le CLIENT instanciant le Builder.

2- Le CLIENT instancie l'objet Directeur, en lui transmettant en param. de son constructeur, le Builder Concret (lequel a déjà été initialisé pour la création d'une arborescence de racine donnée).
Puis sur demande paramétrée, du CLIENT, le Directeur va appeler les méthodes addChild() ou addParent() de son Builder Concret, en leur passant en param. des tags dépendant de ce que lui demandera précisément le CLIENT.
Le Directeur sait les parties à assembler en fonction de ce que lui demande le
CLIENT. Le CLIENT pourrait lui dire: "Ajoute moi une (autre) rubrique "flavors" dans laquelle tu me mettras la liste de flavor suivante:[ flavor_1, flavor_2,...]" ... Et le Directeur s'éxécute:
-addChild("flavors")
-forEach( [ flavor1, flavor2,...] ) builder.addToParent("flavors", flavor_n)

3- Apparemment ici il n'y a pas de notion de Builder Abstrait.


J'ai malgré tout quelques remarques: :bug:

a) Je me dis qu'une seule méthode, à savoir addToParent() , aurait suffit, car en effet dans l'exemple: builder.addChild("flavors") équivaut à builder.addToParent("activity", "flavors") !? ...sauf qu'avec addChild la racine est sous-entendue égale à "activity".
Ah mais non ça y est je sais...: c'est parce-que le Directeur n'a pas connaissance du nom de la racine, ici "activity", laquelle n'est connue que du CLIENT qui a paramétré le Builder. Ok...OK... :roll:
(j'me fais fais mes questions réponses, remarque ça peut intéresser alors je laisse... ;) ) donc addChild() est bien utile!!

b) Quand le Directeur dit au Builder: builder.addToParent("flavors", flavor_n) :
Comment le Builder peut savoir de quel tag "flavors" il s'agit au final, puisqu'il peut y en avoir plusieurs dans l'arborescence, par exemple:
<activity>
<flavors>
<flavor>Vanille</flavor>
<flavor>Fraise</flavor>
</flavors>

<flavors>
<flavor>Choco</flavor>
</flavors>

...
</activity>

?? euh là j'ai pas d'auto-réponse!!! :?

Sinon l'idée est là et je te remercie grandement Patriarch24 de ton effort de recherche et pour cette trouvaille.
;)

Citation:

---

Sinon l'idée est là et je te remercie grandement Patriarch24 de ton effort de recherche et pour cette trouvaille.

---

Ben c'est google qu'il faut remercier, ma recherche est "composite builder", le résultat c'est le premier lien ; ça ne demande pas beaucoup d'efforts :mrgreen:

:mrgreen:

Tant que je te tiens Patriarch24!!
Est-ce que t'aurais une réponse pour ma dernière question??? :roll:

Citation:

---

Comment le Builder peut savoir de quel tag "flavors" il s'agit au final

---

Ben il suffit d'améliorer l'interface, en ajoutant une clé pour l'élément ajouté, histoire de savoir duquel on parle quand on le réutilise (différencier le nom de balise et l'identifiant de l'objet en fait).

Ouais d'accord je vois le genre...

Cool Patriarch24 et merci encore de partager aussi généreusement ton savoir et tes opinions.

;)

Longue vie à Patriarch24, longue vie....
:lahola::lahola::lahola::lahola: