嗨，那些聪明的人。这是一个SOS。
我遇到了很大麻烦。在我的Web应用程序中有一个对象（说它是对某事的请求）。用户提交他/她的请求。在此之后，它会出现在那些可以批准/不批准该请求的人身上。在提交到批准/不批准期间，可以对请求采取许多措施。我必须向用户提供动作面板（链接集合），使用它可以修改请求的状态。
现在根据处理请求的哪个阶段，不允许某些操作。此外，如果已采取某些行动，则排除了采取其他行动的可能性。
总的来说，它创造了一个非常复杂的允许/禁止行动矩阵，我的小脑袋无法处理它。
我创建了一些静态类/方法，它们根据请求的状态返回允许的操作数组。应用程序可以处于大约20个状态。我已根据状态删除/禁用该状态下无法执行的操作的链接。 现在出现的问题是假设请求处于状态X.
现在，如果在过去的行动中我已经接受了请求，我们可能不会允许l或基于此一些任意行为m，n，o。
在编写了获取20个状态的链接数组的所有方法之后，我必须根据过去的操作历史（存储在sql db中）过滤数组，这是非常大的任务。
请建议我一些更易于实施和高效的模式。这让我很紧张。
答案 0 :(得分：1)
据我了解，您有一个真实的工作流场景。在这种情况下，我会：
如果可能，将整个状态建模为单个实体（具有固定数量字段的单行）。我不会将此模型化为一系列行动。
将每个操作建模为行中的某些更改。当用户输入一些数据时很明显，但我也会将每个接受模型建模为 - 布尔字段或状态字段 - 取决于接受是由独立部门完成还是在单个部门中接受级联。
此外，可能存在某个特定参数被接受并且参数可能在将来发生变化，需要新接受的情况。在这种情况下，我会将这种情景建模为两个字段。 On为参数值，第二个为可接受值。我会根据这两个领域的不同来决定是否还需要接受。这允许实现一些阈值。
将状态建模为单行，我会实现独立的行动允许谓词。
我认为第4点是最重要的一点。如果您能够实现独立谓词以启用操作，那么您将来可以轻松修改它们。
正确实施1-3后，您将能够轻松实现接受撤销，这可能是必需的，在这种情况下可能会使整体代码规模变小。
答案 1 :(得分：0)
听起来像是状态机工作流程的工作，或者是一些巨大的嵌套交换机（你喜欢的）。
答案 2 :(得分：0)
我想到的第一件事是：Statemachine。每个国家都是某种对象。所有状态都有一些方法“processRequest”，它将执行转换为下一个状态。
我想到的第二件事 - 这些州必须像树或图一样被组织起来。该图表表示请求的历史记录。你从最初的状态开始。您收到请求A，然后继续执行状态A.之后，您将收到请求B，然后转到AB。根据您的描述，湿润状态AB等于BA不清楚。
这样，你获得的状态远远超过你现在拥有的20个州，但每个州都包括历史。我建议在你必须走的路径（比如之前的AB）之后的命名约定。也许你可以在AB中重用状态A和B，以最小化编码。