Choosing a Design Pattern

Question

I need to design an application that resembles an internal mailing system. However, this is just a course project. No networking required. The professor is just making us put the discussed data structures to work. However, I have been having trouble deciding how to design the application. Let me explain briefly what I have to do and then I will share my thoughts.

I think it would be a good idea if let you know that this is a command line based application. No GUI involved.

The internal mail system consists of 5 different possible states. General, Administrator, User, Moderator, and Compose. It is possible to be only at one state at a time. When the application starts, it enters the General state by default. The only possible command in this state is to log in to some other account (User, Admin, Mod.) The User has basic commands like reading his messages, sending (compose) new ones to some other user, deleting messages, logging out, and a couple more. A User can change to one of two states: Compose or General. To get to the Compose state, the User must use the command compose. In this state you compose a message to some other user. Once you finish composing the message you go back to the User state. The only way a User could go back to General is by logging out.

Admin (which inherits the behavior of User) and Mod are pretty much the same. They can change states as well.

Here's a summary of how it is possible to change state

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

I'm a new to design patterns. I've been reading a lot about them lately. However, this will be the first time I'll implement them. If one of my suggestions seem weird please let me know.

The State Pattern seems like a great idea. I lets me change an object state dynamically. However, not all states have the same methods. Administrators has more methods than User. Moderator does not have any of the methods from Admin or User. You can only use General to log in. I think that this will then limit the ability to use State Pattern. Do you have any suggestions for some other pattern?

Another idea I had was something like the following. Since I can ascend and descend states, I could be seen as a stack. For example: a user that is in compose mode.

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

Do you have any ideas on how I could implement that? Is it even possible? Although I'm comfortable with Java the most, C++ or pseudo code is fine.

Thank you very much.

Answer 1

The nice design pattern of this is the "Role object model". It can be applied in a context where:

• you want to handle a key abstraction in different contexts and you do not want to put the resulting context-specific interfaces into the same class interface.
• you want to handle the available roles dynamically so that they can be attached and removed on demand, that is at runtime, rather than fixing them statically at compile-time.
• you want to treat the extensions transparently and need to preserve the logical object identity of the resulting object conglomerate.
• you want to keep role/client pairs independent from each other so that changes to a role do not affect clients that are not interested in that role.

That pattern used three elements: A component (here: your user) that concists of a component core which essencially manages the roles and component roles that provides role specific abilities. Admin, User, Moderator, etc are the roles in your context.

Answer 2

I think that there are mixing two aspects you have to distinguish..

User, Admin and Moderator are roles, while General, LogedIn and Compose are states. Thus I think that you should compine both state and role design patterns together.