Quel patron de conception pour des noeuds

Bonjour,

J’ai une classe Node contenant un nom, un type et un tableau de paramètre (dynamique):

Code:

---

1 2 3 4

class Node string name() int type() paramArray params()

---

On est, a priori, sur une approche RTTI ou chaque nœud reste sur une classe Node (pas d’héritage) mais un attribut de type qui permet de l’identifier.

Ducoup je suppose que d’autres classes permettent de gérer les nœuds en fonction de leur type.

Ma question est : Quel patron(s ?) de conception permet de s’occuper de la création/destruction des nœuds en fonction de leur type.

Un gros merci d’avance ! :)

S'il n'y a aucun héritage et juste un membre qui définit le type, pourquoi aurais-tu besoin de quoi que ce soit d'autre qu'un constructeur ?

Merci pour la réponse.

Citation:

---

S'il n'y a aucun héritage et juste un membre qui définit le type, pourquoi aurais-tu besoin de quoi que ce soit d'autre qu'un constructeur ?

---

Parce que la construction d'un nœud (ces paramètres) dépends de type.

A priori, builder est le patron qu'il me faut, mais n’étant pas expert, je passe peut-être a cote d'un patron plus adapte.

Salut,

Comme l'a si bien dit Einstein

Citation:

---

Il faut rendre les choses aussi complexes que nécessaires, mais guère plus

---

En XP (Xtrem Programming), nous dirions les choses encore plus simplement :

Citation:

---

KISS et (Keep It Simple, Stupid)
YAGNI (You Ain't Gonna Need It)

---

Pour l'instant, tu travailles sur la notion de noeuds. Concentre toi donc sur la notion de noeuds : comment il faut les manipuler (!!! manipuler est un terme différent de construire :D ), comment il faut faire et défaire leurs relations, comment il faut les traverser, les combiner, et tout ce qui s'en suit.

Tu auras bien assez de travail comme cela ;)

Par la suite, tu te dira que ce serait en effet pas mal si tu pouvait "automatiser" leur création (au lieu de "simplement" leur fournir les données "telles qu'ils les utilisent"). Il sera alors toujours bien temps de réfléchir à une manière de le faire ;)

NOTA: Quelque soit la forme, lorsque l'on décide de fournir un moyen pour connaître le type d'un noeud, moi, je deviens particulièrement frileux à cause de la très forte responsabilité de non respect de l'OCP que cela induit.

Car il faut bien te dire que chaque fois que tu utiliseras cette fonction, ce sera pour décider de "ce qu'il faut faire" par la suite. Tu auras donc à chaque fois une série de if ... else (ou peut-être de switch ... case, selon le cas) qui devra s'assurer de prendre toutes les possibilités en charge.

Tant que le nombre de type de noeuds reste fixe, il n'y aura pas de problème. Mais, si "un jour", tu décides de rajouter un nouveau type de noeud (et ce jour a de très grosses chances d'arriver, à défaut de connaître ton projet), tu devras corriger ces séries partout où elles apparaîtront. Et vu le nombre de fois où ces séries de tests apparaîtront, je suis prêt à parier que tu en oublieras quelques unes, en provoquant au passage quelque bugs ... surprenants. :aie:

Citation:

---

Envoyé par koala01

Par la suite, tu te dira que ce serait en effet pas mal si tu pouvait "automatiser" leur création (au lieu de "simplement" leur fournir les données "telles qu'ils les utilisent"). Il sera alors toujours bien temps de réfléchir à une manière de le faire ;)

---

Bah justement, j'y suis. :)

Citation:

---

Envoyé par koala01

Car il faut bien te dire que chaque fois que tu utiliseras cette fonction, ce sera pour décider de "ce qu'il faut faire" par la suite. Tu auras donc à chaque fois une série de if ... else (ou peut-être de switch ... case, selon le cas) qui devra s'assurer de prendre toutes les possibilités en charge.

---

C'est ce que je souhaite eviter, et c'est justement pour ca que je demande si il y a un pattern qui permet d'englober ce principe. :)

Le double dispatch (comme le patron "visiteur", par exemple) pourrait te l'éviter, à la seule condition que tu aies une hiérarchie de noeuds.

Cependant, il y a "à boire et à manger" dans le patron de conception visiteur, si bien qu'il n'est réellement intéressant que quand on a une hiérarchie relativement figée (qu'il ne risque "pas trop" d'y avoir de nouvelles classes dérivées qui apparaissent chaque jour)

Et, bien sur, avec le double dispatch et le patron visiteur, nous sommes d'avantage du coté de la manipulation que du coté de la création:aie:...

Pour la création des éléments, un "mix" fabrique (pour les éléments eux-même)+ builder (pour les éléments constitutifs des noeuds) est souvent intéressant ;)

Ou plutôt : on n'a pas vraiment le choix lorsque l'on est à la recherche d'un patron de conception pour la création d'élément polymorphes :aie:

Merci pour les informations, ça semble répondre a mon besoin. :)