Choix d'un motif de conception

Question

Je dois concevoir une application qui ressemble à un système de publipostage interne. Cependant, ceci est juste un projet de cours. Aucun réseau requis. Le professeur nous fait juste mettre les structures de données discutées au travail. Cependant, j'ai eu du mal à décider comment concevoir l'application. Laissez-moi vous expliquer brièvement ce que je dois faire et ensuite je partagerai mes pensées.

Je pense que ce serait une bonne idée si vous savez qu'il s'agit d'une application basée sur une ligne de commande. Aucune interface graphique impliquée.

Le système de messagerie interne se compose de 5 états possibles différents. Général, Administrateur, Utilisateur, Modérateur et Composer. Il est possible d'être seulement à un état à la fois. Lorsque l'application démarre, elle passe à l'état Général par défaut. La seule commande possible dans cet état est de se connecter à un autre compte (Utilisateur, Admin, Mod.) L'Utilisateur dispose de commandes de base comme lire ses messages, en envoyer de nouveaux à un autre utilisateur, supprimer des messages, se déconnecter, et un couple de plus. Un utilisateur peut passer à l'un des deux états suivants: Composer ou Général. Pour accéder à l'état Composer, l'utilisateur doit utiliser la commande compose. Dans cet état, vous composez un message à un autre utilisateur. Une fois que vous avez fini de composer le message, vous revenez à l'état Utilisateur. Le seul moyen pour un utilisateur de revenir à General est de se déconnecter.

Admin (qui hérite du comportement de l'utilisateur) et Mod sont à peu près les mêmes. Ils peuvent aussi changer d'état.

Voici un résumé de la façon dont il est possible de changer d'état

General |----->Admin 
     | |---->User(limited) 
     | |---->Compose 
     | 
     |----->Moderator 
     | 
     |----->User 
     | |---->Compose 

Je suis un nouveau pour concevoir des modèles. J'ai beaucoup lu à leur sujet ces derniers temps. Cependant, ce sera la première fois que je les implémenterai. Si l'une de mes suggestions semble bizarre, faites-le moi savoir.

Le motif d'état semble être une excellente idée. Je me laisse changer un état d'objet dynamiquement. Cependant, tous les états n'ont pas les mêmes méthodes. Les administrateurs ont plus de méthodes que l'utilisateur. Le modérateur n'a aucune des méthodes de l'administrateur ou de l'utilisateur. Vous ne pouvez utiliser General que pour vous connecter. Je pense que cela limitera la possibilité d'utiliser State Pattern. Avez-vous des suggestions pour un autre modèle?

Une autre idée que j'avais était quelque chose comme ce qui suit. Puisque je peux monter et descendre des états, je pourrais être vu comme une pile. Par exemple: un utilisateur en mode composition.

\  / 
| Compose | <---- top (current state) 
| User | 
| General | 
----------- 

Avez-vous des idées sur la façon dont je pourrais implémenter cela? Est-ce même possible? Bien que je sois le plus à l'aise avec Java, le code C++ ou pseudo est très bien.

Answer 1

Le motif de conception agréable de ceci est le "Role object model". Elle peut être appliquée dans un contexte où:

• vous voulez gérer une abstraction clé dans des contextes différents et que vous ne voulez pas mettre les interfaces spécifiques au contexte résultant dans la même interface de classe.
• Vous souhaitez gérer dynamiquement les rôles disponibles afin qu'ils puissent être attachés et supprimés à la demande, c'est-à-dire lors de l'exécution, plutôt que de les corriger statiquement au moment de la compilation.
• Vous souhaitez traiter les extensions de manière transparente et devez conserver l'identité d'objet logique du conglomérat d'objet résultant.
• Vous souhaitez conserver les paires rôle/client indépendantes les unes des autres afin que les modifications apportées à un rôle n'affectent pas les clients qui ne sont pas intéressés par ce rôle.

Ce modèle utilise trois éléments: un composant (ici: votre utilisateur) concists d'un composant central qui gère essencially les rôles et les rôles composant qui fournit le rôle des capacités spécifiques. Admin, Utilisateur, Modérateur, etc sont les rôles dans votre contexte.

Answer 2

Je pense qu'il ya mélange de deux aspects que vous devez distinguer ..

utilisateur, Administrateur et Modérateur sont rôles, tandis que général, LogedIn et Compose sont états. Ainsi, je pense que vous devez compiler à la fois état et rôle modèles de conception ensemble.