Design patterns 是否存在允许为不同角色建模不同动作的设计模式？

我们有一个要求，根据用户的角色，他们可以在下拉菜单中使用不同的选项。（所选选项将驱动记录上的操作）

这是最初实现的，不是我自己实现的，我急忙补充说，通过使用if语句，并将允许的选项存储在数组中

正如预测的那样，“规则”已经变得更加复杂，新角色已经被添加，因此现在它已经变成了一堆邪恶的意大利面代码，这实际上可能需要添加虚拟变量来跟踪正在发生的事情

我的问题是，有没有一种设计模式可以帮助解决这个问题

一个例子

角色审批人在阅读他们不拥有的记录时，只会看到批准、拒绝和提交审批。如果他们拥有该记录，那么他们只能看到拒绝

角色CSA可以查看已审核、批准或需要返工，因为如果读取未被拒绝的记录，如果该记录已被拒绝，那么简洁地解释会变得复杂

---

我们还有3个角色…：（

一种可能的解决方案可以是，因此它可以动态地为对象添加职责。还提供了一种灵活的替代方法，以子类化来扩展功能。在您的情况下，实现可以是这样的：

//Component
public abstract class Option{   
    // defines the interface for objects that can have responsibilities added to them dynamically.
}

//ConcreteComponent 
public class ApproveOption extends Option{
    //defines an object to which additional responsibilities can be attached.
}

//ConcreteComponent 
public class RejectOption extends Option{
    //defines an object to which additional responsibilities can be attached.
}

public abstract class Decorator{   
    //maintains a reference to a Component object and defines an interface that conforms to 
    //Component's interface.
}

public class OptionsDecorator extends Decorator{   
    //adds (Visible) responsibilities to the component depending from the Role.
}

或通过允许对象在其内部状态更改时更改其行为。该对象将显示为更改其类。并成为：

//Context
public class Role{  
    //defines the interface of interest to clients
    //maintains an instance of a ConcreteState subclass that defines the current state.
}

public abstract class State{
    //defines an interface for encapsulating the behavior associated with a particular state 
    //of the Context.
}

//Concrete State
public class ApproverState extends State{
    //each subclass implements a behavior associated with a state of Context
}

public class CSAState extends State{
    //each subclass implements a behavior associated with a state of Context
}

---

我会尝试一下状态模式。规范模式可能也会起作用。相关问题的答案是：我在考虑状态设计模式，但没有考虑装饰器模式，我会尝试对这两种模式进行POC，看看哪一种效果最好。如果相同的操作做得不同，感谢装饰器是有意义的。每个装饰器c重新定义操作（扩充）。OP明确指出，根据角色不同，它们是不同的操作。这似乎不太合适，至少不是你解释的方式。状态模式可能有意义，但你没有充实操作。我认为这个答案不够详细。