我需要设计一个类似于内部邮件系统的应用程序。但是，这只是一个课程项目。无需网络连接。教授只是让我们把讨论过的数据结构付诸实践。但是，我一直无法决定如何设计应用程序。让我简要解释一下我必须做什么，然后我会分享我的想法。
如果您知道这是一个基于命令行的应用程序，我认为这是一个好主意。没有涉及GUI。
内部邮件系统包含5种不同的可能状态。常规，管理员，用户，主持人和撰写。有可能一次只能处于一种状态。应用程序启动时，默认情况下进入常规状态。此状态下唯一可能的命令是登录其他帐户（User，Admin，Mod。）用户有基本命令，如阅读他的消息，向其他用户发送（撰写）新消息，删除消息，注销，还有几个。用户可以更改为以下两种状态之一：撰写或常规。要进入Compose状态，用户必须使用命令compose。在此状态下，您将向其他用户撰写消息。完成撰写邮件后，您将返回“用户”状态。用户返回General的唯一方法是退出。
Admin（继承User的行为）和Mod几乎相同。他们也可以改变状态。
以下是如何更改状态
的摘要General |----->Admin
| |---->User(limited)
| |---->Compose
|
|----->Moderator
|
|----->User
| |---->Compose
我是设计模式的新手。我最近一直在读他们很多。但是，这将是我第一次实施它们。如果我的一个建议看起来很奇怪，请告诉我。
状态模式似乎是一个好主意。我让我动态更改对象状态。但是，并非所有州都采用相同的方法。管理员拥有的方法多于用户。主持人没有管理员或用户的任何方法。您只能使用常规登录。我认为这将限制使用状态模式的能力。你对其他模式有什么建议吗？
我的另一个想法是以下内容。由于我可以上升和下降状态，我可以被视为一个堆栈。例如：处于撰写模式的用户。
\ /
| Compose | <---- top (current state)
| User |
| General |
-----------
您对我如何实现这一点有什么想法吗？它甚至可能吗？虽然我对Java最熟悉，但C ++或伪代码都很好。
答案 0 :(得分：1)
这个漂亮的设计模式是"Role object model"。它可以应用于以下环境：
- 您希望在不同的上下文中处理关键抽象，并且您不希望将生成的特定于上下文的接口放入同一个类接口中。
- 您希望动态处理可用角色，以便可以按需添加和删除它们 在运行时，而不是在编译时静态修复它们。
- 您希望透明地处理扩展，并且需要保留结果的逻辑对象标识 对象集团。
- 您希望保持角色/客户端对彼此独立，以便对角色的更改不会影响客户端 那个角色不感兴趣。
该模式使用了三个元素：组件（此处为：您的用户），其中包含组件核心，它基本上管理角色和组件角色提供角色特定能力。 管理员，用户，主持人等是您上下文中的角色。
答案 1 :(得分：1)
我认为你必须要区分两个方面......
用户，管理员和主持人是角色，而常规，< em> LogedIn 和 Compose 是状态。因此，我认为您应该同时将州和角色两种设计模式进行比较。