选择设计模式

Question

我需要设计一个类似于内部邮件系统的应用程序。然而，这只是一个课程项目。无需联网。教授只是让我们将讨论的数据结构付诸实践。但是，我一直无法决定如何设计应用程序。让我简要解释一下我必须做什么，然后我将分享我的想法。

如果让您知道这是一个基于命令行的应用程序，我认为这将是一个好主意。不涉及 GUI。

内部邮件系统由 5 种不同的可能状态组成。常规、管理员、用户、版主和撰写。一次可能只处于一种状态。应用程序启动时，默认进入General状态。在这种状态下唯一可能的命令是登录到其他帐户（用户、管理员、国防部）。用户具有基本命令，例如阅读他的消息、向其他用户发送（撰写）新消息、删除消息、注销、还有几个。用户可以更改为以下两种状态之一：撰写或常规。要进入撰写状态，用户必须使用命令compose。在这种状态下，您向其他用户撰写消息。完成编写消息后，您将返回用户状态。用户返回常规的唯一方法是注销。

Admin（继承了 User 的行为）和 Mod 几乎相同。他们也可以改变状态。

这里总结了如何改变状态

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

我是设计模式的新手。我最近读了很多关于他们的书。但是，这将是我第一次实施它们。如果我的建议之一看起来很奇怪，请告诉我。

状态模式似乎是个好主意。我让我动态更改对象状态。但是，并非所有州都有相同的方法。管理员比用户有更多的方法。版主没有任何来自管理员或用户的方法。您只能使用 General 登录。我认为这将限制使用 State Pattern 的能力。您对其他模式有什么建议吗？

我的另一个想法是这样的。由于我可以上升和下降状态，我可以被视为一个堆栈。例如：处于撰写模式的用户。

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

您对我如何实现它有任何想法吗？甚至可能吗？虽然我最熟悉 Java，但 C++ 或伪代码都可以。

Answer 1

这个很好的设计模式是"Role object model"。它可以应用在以下环境中：

• 您希望处理不同上下文中的关键抽象，并且不希望将生成的特定于上下文的接口放入同一个类接口中。
• 您希望动态处理可用角色，以便可以按需附加和删除它们，即 在运行时，而不是在编译时静态修复它们。
• 您希望透明地处理扩展并需要保留结果的逻辑对象标识 对象集合体。
• 您希望保持角色/客户端对彼此独立，以便角色更改不会影响客户端 对那个角色不感兴趣的人。

该模式使用了三个元素：一个组件（这里：你的用户），它由一个组件核心组成，它主要管理角色和组件角色 em> 提供角色特定的能力。 Admin、User、Moderator 等是您上下文中的角色。

Answer 2

我认为你必须区分两个方面..

User、Admin和Moderator是角色，而General、LogedIn 和 Compose 是状态。因此，我认为您应该将 state 和 role 设计模式结合在一起。