Oop 基于角色的行为模式

我参与了一个应用程序迁移项目。该应用程序应该根据当前用户角色执行一些逻辑，因此代码中到处都有这样的代码片段：

if ("Role1".equals(user.getUserRole())){
    operationVersionForRole1();
} else if ("Role2".equals(user.getRole())){
    operationVersionForRole2();  
} else if ("Role3".equals(user.getRole())){
    operationVersionForRole3();
}

---

大约有5个角色和近50个操作，有些操作对于某些角色来说非常复杂（几乎1000行代码），因此编程风格使得源代码凌乱且难以理解。在这种情况下，是否有任何已知的设计模式可以帮助组织源代码？嵌套的“if-else”感觉不对

您可以这样做，其中所有操作都扩展了

操作

超类，并且

角色

是实际对象而不是字符串：

public abstract class Operation {
  public void execute(User user) {
    user.getRole().apply(this);
  }

  public abstract void operationForRole1();
  public abstract void operationForRole2();
  public abstract void operationForRole3();
}

public enum Role {
  ROLE1 { public void apply(Operation op) { op.operationForRole1(); } },
  ROLE2 { public void apply(Operation op) { op.operationForRole2(); } },
  ROLE3 { public void apply(Operation op) { op.operationForRole3(); } };

  public abstract void apply(Operation op);
}

---

每个

操作

然后实现各种角色的逻辑，客户端只需调用

操作。执行（用户）

。没有

if-else

任何地方。

您可以这样做，所有操作都扩展了

操作

超类，并且

角色

是一个实际对象而不是字符串：

public abstract class Operation {
  public void execute(User user) {
    user.getRole().apply(this);
  }

  public abstract void operationForRole1();
  public abstract void operationForRole2();
  public abstract void operationForRole3();
}

public enum Role {
  ROLE1 { public void apply(Operation op) { op.operationForRole1(); } },
  ROLE2 { public void apply(Operation op) { op.operationForRole2(); } },
  ROLE3 { public void apply(Operation op) { op.operationForRole3(); } };

  public abstract void apply(Operation op);
}

每个

操作

然后实现各种角色的逻辑，客户端只需调用

操作。执行（用户）

。没有

if-else

任何地方。

它不是一个抽象工厂吗？它提供了一个接口，用于创建相关或从属对象的族，而不指定它们的具体类？指定的角色将是创建具体实现的参数。而

operationVersionForRoleX

可以设计为不同的

ioOperation

接口实现或策略

interface IOperation  
{ 
    void Execute();
}

class OperationVersionForRoleX : IOperation
{
    public void Execute()
    {
        // …
    }
}

string role = "roleX";
IOperation operation = operationFactory.Create(role);
operation.Execute();

它不是一个抽象工厂吗？它提供了一个接口来创建相关或从属对象的族，而不指定它们的具体类？指定的角色将是创建具体实现的参数。而

operationVersionForRoleX

可以设计为不同的

ioOperation

接口实现或策略

interface IOperation  
{ 
    void Execute();
}

class OperationVersionForRoleX : IOperation
{
    public void Execute()
    {
        // …
    }
}

string role = "roleX";
IOperation operation = operationFactory.Create(role);
operation.Execute();

---

与卡萨布兰卡的回答类似

• 我通常避免枚举中的业务逻辑，因为它们的工作只是唯一性，并且在其他方面几乎不如类
  公共枚举角色{

  ROLE1 { public Actions getActions(){ return new Role1Actions() } },
  ROLE2 { public Actions getActions(){ return new Role2Actions() } },
  ROLE3 { public Actions getActions(){ return new Role3Actions() } };
  

  }

• 我将使Actions与每个角色可以执行的操作类型尽可能多的方法接口

公共接口操作{

void action1();
// useful when there are more than 1 different actions per role
// even if only 1 now, there will be more in the future
vpod action2();
}

• 然后，只需使用您可以从角色获得的操作
  user.getUserRole（）.action1（）
  user.getUserRole（）.action2（）

---

与卡萨布兰卡的回答类似
• 我通常避免枚举中的业务逻辑，因为它们的工作只是唯一性，并且在其他方面几乎不如类
  公共枚举角色{

  ROLE1 { public Actions getActions(){ return new Role1Actions() } },
  ROLE2 { public Actions getActions(){ return new Role2Actions() } },
  ROLE3 { public Actions getActions(){ return new Role3Actions() } };
  

  }

• 我将使Actions与每个角色可以执行的操作类型尽可能多的方法接口

公共接口操作{

void action1();
// useful when there are more than 1 different actions per role
// even if only 1 now, there will be more in the future
vpod action2();
}

• 然后，只需使用您可以从角色获得的操作
  user.getUserRole（）.action1（）
  user.getUserRole（）.action2（）

---

这意味着每个角色的所有操作逻辑将仅在一个类中。有些操作相当复杂（几乎1000行代码）。这不会产生BLOB并违反SRP吗？不是一个类，一个接口。实现类可以是更多类的派生。简言之，这是一种策略设计模式，意味着每个角色的所有操作逻辑都只在一个类中。有些操作相当复杂（几乎1000行代码）。这不会产生BLOB并违反SRP吗？不是一个类，一个接口。实现类可以是更多类的派生。简而言之，这是一种策略设计模式