用例类可设多个业务逻辑处理方法吗？是否违反单一职责原则？

1. 返回状态枚举+GetError()的设计是否可行？ #

可行，但并非最优方案。这种方式能让控制器区分操作结果，但存在两处明显局限：

• 状态枚举与错误信息耦合：新增状态时需同步维护错误信息逻辑，容易出现遗漏或不一致。
• 调用流程繁琐：控制器需先判断状态，再调用GetError()获取信息，多了一层冗余操作。

更推荐用结果对象封装的方式，将状态、错误信息、业务数据（如创建后的User）整合到一个类中，示例代码如下：

public class SignUpResult
{
    public SignUpStatus Status { get; }
    public string ErrorMessage { get; }
    public User CreatedUser { get; }

    private SignUpResult(SignUpStatus status, string errorMessage = null, User user = null)
    {
        Status = status;
        ErrorMessage = errorMessage;
        CreatedUser = user;
    }

    public static SignUpResult Success(User user) => new SignUpResult(SignUpStatus.Success, user: user);
    public static SignUpResult UserExists() => new SignUpResult(SignUpStatus.UserExists, "该用户已存在");
    public static SignUpResult InvalidInput(string message) => new SignUpResult(SignUpStatus.InvalidInput, message);
    public static SignUpResult SystemError(string message) => new SignUpResult(SignUpStatus.SystemError, message);
}

public enum SignUpStatus
{
    Success,
    UserExists,
    InvalidInput,
    SystemError
}

此时用例的Execute方法直接返回SignUpResult，控制器拿到结果后可直接判断状态、获取错误信息与业务数据，逻辑更连贯。

2. 是否违反单一职责原则？ #

你的设计不会违反单一职责原则。单一职责要求类仅负责一个核心功能领域，SignUp类的核心职责是处理用户注册业务，返回状态、提供错误信息都是为完成该职责的辅助逻辑，不属于额外职责范畴。

需注意：若将与注册无关的逻辑（如登录、密码重置）塞进该类，才会违反单一职责。

3. 用例类是否可以拥有多个处理业务逻辑的方法？ #

可以，但需确保所有方法都属于同一业务用例范畴。例如SignUp类中可包含：

• Execute(UserData data)：处理完整注册流程
• ValidateInput(UserData data)：单独执行输入校验（需复用校验逻辑时）
• CheckUserExists(string email)：单独检查用户是否存在

但如果方法涉及完全独立的业务（如新增ResetPassword方法），则应拆分为独立的用例类（如ResetPassword类），否则会导致类臃肿、职责混乱，违反单一职责原则。

内容的提问来源于stack exchange，提问作者Samuel Ives