java第一次作业：枚举类型应用场景

场景1：状态/类型定义（最常用）
在日常业务开发里，我们经常会遇到各种固定的有限分类、业务状态，比如订单的支付状态、账号的权限类型、商品的上架状态等等。
如果不用枚举，我们通常会用数字 0、1、2 或者零散字符串来标记状态，代码可读性极差，新人接手完全看不懂数字代表什么含义，还很容易写错数值、出现魔法值 bug。
用枚举来定义之后，每个状态都有专属的名称、含义、描述，代码直观易懂，还能限制传入值的范围，从根源上避免非法参数。
例如订单状态：
public enum OrderStatus{
UNPAID(0,“待付款”)，
PAID(1,“已付款”),
SHIPPED(2,“已发货”)，
FINISHED(3,“已完成”)，
CANCELLED(4,“已取消”)；

private final int code;
private final String desc;
}

场景2：策略模式（替换大量if/else）：
例如：
（传统写法）
public double calculatePrice(String type, double price){
if("NORMAL".equals(type)){
return price;
}else if("VIP".equals(type)){
return price * 0.9;
}else if("SVIP".equals(type)){
return price * 0.7;
}
// 新增优惠类型还要继续加else
}

（优化写法）
public enum DiscountType {
NORMAL{
@Override public double calc(double p) {return p;}
},
VIP{
@Override public double calc(double p) {return p * 0.9;}
},
SVIP{
@Override public double calc(double p) {return p * 0.7;}
};

// 抽象方法，每个枚举自己实现逻辑
public abstract double calc(double price);
}

场景3：统一返回码（后端接口必备）
做后端开发写接口的时候，需要给前端返回统一的响应提示，比如成功、参数错误、权限不足、服务器异常、登录过期等固定提示。
如果每次手动写 code 和 msg，很容易出现前后码不一致、文案重复杂乱的问题。用枚举封装全局响应结果，就能做到全项目返回格式完全统一，维护起来也极其方便。
示例：
public enum ResultCode {
SUCCESS(200, "请求成功"),
PARAM_ERROR(400, "参数校验失败"),
NO_AUTH(403, "无访问权限"),
NOT_FOUND(404, "资源不存在"),
SERVER_ERROR(500, "服务器繁忙，请稍后重试");

public final int code;
public final String message;
}
全局接口统一使用这个枚举返回，前端也能固定解析状态码做统一拦截、统一弹窗提示