Discussion :

[Rockz]

Salut,

Je cherche des design patterns pour le cas d'utilisation suivant, s'inscrivant dans le thème "gestion de rôles-utilisateur" :

Chaque utilisateur de l'application peut endosser dynamiquement (à l'exécution) différents rôles. Ces rôles peuvent définir différemment une même fonctionnalité, étendre une même fonctionnalité, mais également adjoindre des fonctionnalités qui leur sont propres. En parrallèle, une gestion des rôles doit déterminer les incompatibilités potentielles lors de l'ajout/suppression d'un rôle (contraintes et dépendances).

Dans un exemple pris au hasard, l'utilisateur a le rôle de "membre d'association", puis a le rôle de "trésorier d'association", puis le rôle de "fournisseur de l'association". L'ajout et la suppression de ces rôles peut se faire dans n'importe quel ordre, sous couvert d'un gestionnaire de rôles (a-priori).

Ici, la méthode permettant d'accéder au dossier d'un membre de l'association ne sera pas formée de la même manière d'une séquence de rôles à l'autre :

- ajout du rôle membre, puis du rôle trésorier : la méthode du rôle trésorier viendra compléter la méthode existante du rôle membre, pour permettre d'accéder à plus de détail. La méthode de dessin de l'IHM sera complétée pour faire apparaître des onglets de gestion supplémentaires.

- ajout du rôle trésorier seul : la méthode du rôle trésorier doit offrir les mêmes fonctionnalités que précedemment, mais la complétion d'une méthode préexistante n'est plus possible ici.

Le design pattern qui se rapproche le plus de ceci est le DP Décorateur, mais il contraint l'ordre/la séquence dans lequel les objets sont enveloppés/désenveloppés, alors que dans le cas ci-dessus, cet ordre doit être libre.

De plus, le DP décorateur est davantage basé sur l'héritage que sur la composition : l'objet A enveloppe l'objet B pour lui adjoindre des fonctionnalités. Ici, je recherche à la fois héritage et composition : un utilisateur est composé de différents rôles, même si certains rôles sont hérités les uns des autres.

Voilà voilà, gros programe ^^ .
Quel modèle de classes puis-je adopter pour réaliser cela ?

Merci.

[hed62]

Chaque utilisateur de l'application peut endosser dynamiquement (à l'exécution) différents rôles.

Typiquement le pattern Strategy / Stratégie.

mais également adjoindre des fonctionnalités qui leur sont propres.

Potentiellement complexe à mettre en oeuvre (comment savoir les fonctionnalités supllémentaires apportées par tel ou tel rôle ?)

sous couvert d'un gestionnaire de rôles (a-priori).

Un controlleur de construction des différents rôles ? Si oui, recherche Factory, si non, laisse tomber, ce sera un simple outil de contrôle.

Tu peux avoir plusieurs rôles à la fois ? Regarde le pattern Décorateur.

Le design pattern qui se rapproche le plus de ceci est le DP Décorateur, mais il contraint l'ordre/la séquence dans lequel les objets sont enveloppés/désenveloppés, alors que dans le cas ci-dessus, cet ordre doit être libre.

Tu veux dire qu'un "trésorier fournisseur" est différent d'un "fournisseur trésorier" ?

De plus, le DP décorateur est davantage basé sur l'héritage que sur la composition :

Je ne suis pas d'accord. Le Décorateur le plus au se compose d'un décorateur de niveau inférieur, etc.. Le seul 'heritage' vient du fait que tous les décorateurs ont la même interface.
D'ailleurs tu le dis toi même :

l'objet A enveloppe l'objet B

Ici "enveloppe" signifie "fait son truc puis délègue"

un utilisateur est composé de différents rôles, même si certains rôles sont hérités les uns des autres.

Ca reste dans le cadre du Décorateur.

Quel modèle de classes puis-je adopter pour réaliser cela ?

Un mix de Décorateur (pour ajout de fonctions), Strategy(changement en cours de route) et Factory(contrôle d'instanciation des rôles) !

[Rockz]

Merci beaucoup pour les pointeurs hed62, je sais quoi potasser maintenant

Citation:

Le design pattern qui se rapproche le plus de ceci est le DP Décorateur, mais il contraint l'ordre/la séquence dans lequel les objets sont enveloppés/désenveloppés, alors que dans le cas ci-dessus, cet ordre doit être libre.

Tu veux dire qu'un "trésorier fournisseur" est différent d'un "fournisseur trésorier" ?

Un utilisateur, disposant des rôles "trésorier puis fournisseur" ou "fournisseur puis trésorier" (les rôles s'additionnent ici, ils ne se substituent pas les uns aux autres) dispose des mêmes fonctionnalités, a la même interface (il ne s'agit pas de fichier Java "interface", mais des I/O d'un objet. Je l'aime pas ce mot, il a trop d'interprétations différentes ^^), les mêmes méthodes à disposition. Par contre, l'attribution des rôles à cet utilisateur se fait différemment dans les deux cas.

Je sous-entendais ici que le DP Décorateur permettrait de passer d'un objet trésorier à un objet fournisseur (trésorier enveloppé dans fournisseur), mais pas l'inverse, alors qu'aucun a-priori ne peut être fait sur l'ordre d'assignation des rôles à un utilisateur.

[Keihilin]

Est-ce qu'il y a quand même une notion de hiérarchie entre les rôles ?

[Rockz]

Salut, tu fais bien de poser la question, car finalement çà montre que çà n'est pas très clair dans mon esprit.

Côté code, un utilisateur "est composé de" plusieurs rôles (composition), mais côté conceptuel/analyse, un utilisateur-trésorier "est une sorte d' " utilisateur (héritage). L'implémentation utilise la composition pour servir un concept d'héritage !! (piquée à JC Vandamme celle-là ).

Finalement, je ne pense pas qu'il doive y avoir de notion d'héritage entre les rôles, car cela restreindrait et forcerait le contenu/les fonctionnalités d'un rôle, introduisant ainsi une relation d'ordre entre eux (par exemple, si un trésorier hérite d'un membre, tout utilisateur possédant le rôle de trésorier disposera implicitement du rôle de membre, ce qui force l'association de rôles et peut être néfaste. Aussi, il s'agit dans ce cas d'une association statique (compilation) et non-dynamique (exécution) des rôles ). De plus, les rôles peuvent être hétérogènes et ne pas se prêter à l'héritage (un fournisseur peut difficilement hériter d'un trésorier (il a des choses en plus, mais aussi des choses en moins), ou alors sur une base infime/générique : identifiant, coordonnées, etc.).

(Je ne cherche pas à te mettre en tort hein , j'essaie de me convaincre aussi, c'est un peu la nébuleuse ce cas là, je connais trop peu les DP et du coup l'ensemble n'est pas ficelé)

[hed62]

Tout est dans le schéma joint.

Mais il reste la plus grande des questions : ici, Fournisseur redéfinit Fonction3. Admettons que PDG redéfinisse aussi Fonction3, lequel est le plus fort ? cela reprend la hiérarchisation des rôles évoquée plus haut.

Du coup, il te faut une Factory de décorateurs. Ben oui, ca te permettra d'insérer les rôles les plus forts au plus proche de la classe utilisateur (qui de se fait ne doit plus porter aucune méthode selon moi, tu dois avoir un décorateur 'de base', de priorité la plus faible)

Cette Factory se base sur un indice de hiérarchie (propre au décorateur => GetIndice():int dans l'interface) pour insérer le rôle au bon endroit. Cela reviens à de la manipulation de pile en ajoutant une notion d'ordre. Un peu étrange une pile ordonnée, mais ca marche très bien.

Pour plus d'infos : http://www.developpez.net/forums/sho...d.php?t=432775

[edit]Avec le schéma joint c'est mieux ...[/edit]

[Rockz]

Merci, je vous donnerai des nouvelles quand j'aurai analysé vos remarques et tenté une implémentation (si le temps presse de trop, çà risque de se finir à la crado, à savoir, dans l'exemple, une classe Membre, une classe Tresorier, et une classe Fournisseur, avec de la duplication de code un peu partout et des structures conditionnelles à foison pour spécialiser les actions selon le type d'utilisateur).

Est-ce qu'il y a quand même une notion de hiérarchie entre les rôles ?

Milles excuses, j'ai lu trop vite ta question, en confondant "hiérarchie" et "héritage" (çà se recoupe un peu néanmoins : en faisant hériter B de A, on se donne l'opportunité de prioriser B sur A, puisque l'on peut surcharger les méthodes de A dans l'objet B).

En y regardant de loin, je souhaite que les rôles s'additionnent/se complètent, et non pas qu'ils se substituent les uns aux autres par le truchement de priorités.

Ainsi, si un utilisateur possède deux rôles qui définissent une même méthode (Fonction3), l'idéal serait de ne pas avoir à choisir l'exécution de l'une ou l'autre des méthodes, mais d'avoir un modèle capable d'exécuter le corps des deux méthodes. Pré-requis : le corps des deux méthodes ne doit pas être redondant/entrer en conflit (travail préalable de délimitation des rôles). Niveau implémentation, on peut imaginer, pour tout appel de méthode dans un rôle, un appel à un gestionnaire de rôle, pour savoir si d'autres rôles "inscrits" disposent de la méthode, et le cas échéant, exécuter ces méthodes dans les autres rôles avant de l'exécuter dans le rôle en cours.

(Si je fabule ou que je pêche de trop par ignorance, vous me le dites hein ? C'est développeur que je veux devenir, pas chef de projet !)

[Keihilin]

Milles excuses, j'ai lu trop vite ta question, en confondant "hiérarchie" et "héritage" (çà se recoupe un peu néanmoins : en faisant hériter B de A, on se donne l'opportunité de prioriser B sur A, puisque l'on peut surcharger les méthodes de A dans l'objet B).

En y regardant de loin, je souhaite que les rôles s'additionnent/se complètent, et non pas qu'ils se substituent les uns aux autres par le truchement de priorités.

Dans ce cas, peut être que le pattern "Chain of Responsibility" est plus approprié...

[hed62]

En effet, ca peut être bien comme pattern.

Mais si deux roles définissent la même fonction, comment il choisit ? comment evaluer l'impact d'une surcharge ? c'est extrèmement complexe !

Ainsi, si un utilisateur possède deux rôles qui définissent une même méthode (Fonction3), l'idéal serait de ne pas avoir à choisir l'exécution de l'une ou l'autre des méthodes, mais d'avoir un modèle capable d'exécuter le corps des deux méthodes. Pré-requis : le corps des deux méthodes ne doit pas être redondant/entrer en conflit (travail préalable de délimitation des rôles). Niveau implémentation, on peut imaginer, pour tout appel de méthode dans un rôle, un appel à un gestionnaire de rôle, pour savoir si d'autres rôles "inscrits" disposent de la méthode, et le cas échéant, exécuter ces méthodes dans les autres rôles avant de l'exécuter dans le rôle en cours.

Je ne crois pas que cela soit des demandes raisonnables : en as tu réellement besoin ? N'y a t il pas une meilleure facon de voir :
toutes les possibilités/fonctionnalités sont listées quelques part , les roles sont des compositions de ces possibilités, les utilisateurs sont composés de roles, par exemple ?

[Keihilin]

En effet, ca peut être bien comme pattern.

Mais si deux roles définissent la même fonction, comment il choisit ? comment evaluer l'impact d'une surcharge ? c'est extrèmement complexe !

Ah oui, j'ai pas dit que c'était simple

C'est justement pour ça que je voulais savoir si il y a une notion de hiérarchie. Histoire de pouvoir faire un choix non-arbitraire en cas de rôles définissant la même fonction.

[hed62]

C'est justement pour ça que je voulais savoir si il y a une notion de hiérarchie. Histoire de pouvoir faire un choix non-arbitraire en cas de rôles définissant la même fonction.

C'est ce qui me semble le plus simple, fiable, efficace en tous cas