校园作业记录应用用户类设计：用字段标识权限还是子类继承？

嘿，这个问题问到点子上了——刚好是小型应用权限设计里最常见的两种思路权衡，我结合校园作业记录的场景给你拆解下：

首先说这种方案的可取之处：

• 对小型应用来说太友好了：实现成本极低，数据库里只需要加个permission整数字段，代码里判断权限就是简单的if语句，开发速度快，完全能满足初期需求。
• 理解成本低：团队里的小伙伴一眼就能看懂0代表管理员、1代表老师这种对应关系，不用绕弯子。

但它的潜在问题也很明显：

• 扩展性极差：如果以后需求变了——比如要加助教、家长这类新用户，或者权限不是线性的（比如老师能发布+批改作业，助教只能批改不能发布），单一int值根本没法表达这种复杂权限，总不能把权限值搞成二进制位运算吧？那可读性直接崩了。
• 魔法数字噩梦：代码里到处飘着if(user.permission == 0)这种判断，过俩月你自己都忘了0、1、2分别对应啥，除非配合枚举，但枚举本质还是映射到int，解决不了组合权限的问题。
• 权限逻辑耦合：所有权限判断都要堆在业务代码里，比如提交作业前判断权限、发布作业前判断权限，以后改权限规则要改N个地方，维护起来头疼。

再说说继承方案的优劣：
它的优势是非常贴合面向对象设计：

• 多态简化逻辑：比如定义AdminUser、TeacherUser、StudentUser三个子类，分别重写canPublishHomework()、canGradeHomework()这类方法，业务代码里直接调用user.canPublishHomework()就行，不用再写一堆权限值判断，代码清爽很多。
• 职责分离：每个子类只处理自己权限范围内的逻辑，不会把所有权限规则都塞在一个大User类里，符合单一职责原则。

但它的不妥之处也不能忽视：

• 继承的局限性：大部分语言都是单继承（比如Java），如果以后出现交叉权限的用户（比如某个老师同时也是管理员），单继承就搞不定了，得靠接口或者组合来补，反而更复杂。
• 类爆炸风险：如果用户类型变多（助教、家长、宿管？），就得不停创建子类，对于小型应用来说完全是过度设计，维护成本直线上升。
• 数据库映射麻烦：不同子类怎么存到数据库？单表继承要加个type字段区分，会有很多空字段；多表继承又要处理关联查询，对于校园作业这种轻量应用来说，纯属给自己找事。

结合你的场景（小型校园作业记录应用），我更推荐：

1. 如果权限只有2-3种线性等级（比如管理员/老师/学生），用int+枚举的方案就足够了，既简单又能避免魔法数字问题，比如：

enum UserRole {
    ADMIN(0), TEACHER(1), STUDENT(2);
    private final int code;
    UserRole(int code) { this.code = code; }
    public int getCode() { return code; }
}

2. 如果以后要加细分权限（比如老师能批改不能删作业，管理员能删不能提交），别用int了，换成组合式权限：给User类加一个Permission对象，里面用多个boolean或者枚举集合来定义具体权限项，比如：

class Permission {
    boolean canPublishHomework;
    boolean canGradeHomework;
    boolean canDeleteHomework;
    boolean canSubmitHomework;
    // getter、setter、构造方法
}

这种方式灵活性远高于单一int，又比继承方案简单，适合小型应用的迭代。

至于继承方案，除非你确定用户类型不会变、权限逻辑差异极大，否则初期真没必要上——毕竟小型应用的核心是快速落地，过度设计反而拖慢进度。

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