Discussion :

[neoncyber]

Bonjour,
Je pensai appliquer le pattern composite, car je voulais faire un graphique avec des noeuds relié entre eu, mais ce que je comprend pas c'est que dans ce cas la qu'elle est l'interet a faire une distinction entre un noeud et une feuille...
Pourquoi je pourrai pas dire que toutes les feuille son des noeud avec zero feuille. Parce que de plus si je veux rajouter une feuille a une feuille, je serrai obliger de le transformer en noeud...
Donc j'ai l'impression que le pattern composite va compliquer le code pour rien...

[Desboys]

Bonjour,

J'ai l'impression que vous énoncez un problème tout en donnant sa solution.

Un noeud d'arbre est un candidat typique du pattern Composite.
Une feuille est un noeud n'ayant pas de noeud enfant.

Vous voulez garder la possibilité d'agrandir votre arbre. Peut-être que la notion de feuille peut être portée sans spécialisation de la notion de Noeud.

On peut très bien créer une méthode estUneFeuille() sur le type Noeud, qui vérifie la règle énoncée plus haut.

Cordialement,
Sébastien

[neoncyber]

Merci de cette réponse, en effet dans ma question je donne ce qui me semble pour moi être la bonne réponse (sans pattern) mais j'aimerai avoir d'autres avis pour mieux trancher. Je vais donc expliquer un peu plus l'objectif du model.


Je suis en train de modéliser mes object metier et il est donc important qu'il n'y est pas de choses inutile dans le model.


Je voudrais faire quelques choses qui ressemble à un gestionnaire de tâches, chaque tâches peut être composé de plusieurs sous tâches, de cet énoncé j'en est tiré deux schema et je n'arrive pas trop à me décider même si je penche plutôt à ne pas utiliser dans mes classes métier le design pattern composite.


Voici le schema :