合理划分类的关键是找对事物、分清职责、控制边界；应识别有生命周期的实体，遵循单一职责原则，用接口和组合替代泛化继承与模糊命名。
合理划分类是面向对象设计的关键起点，核心在于“找对事物、分清职责、控制边界”。不是所有名词都该变成类，也不是越细越好；重点是让每个类有明确的现实对应、单一的修改原因、清晰的协作关系。
从问题域中识别真实实体
先通读需求描述，圈出具有独立状态和行为的名词，排除纯动作、形容词或临时数据。例如“用户登录”里，“用户”“密码”“验证码”中，只有“用户”具备持续状态（账号、角色、头像）和行为（登录、修改资料），适合建类；“验证码”只是临时凭证，更适合作为方法参数或简单值对象。
- 优先选有生命周期的实体：如订单、商品、购物车、支付流水
- 警惕“管理器”“处理器”“工具类”这类泛化命名——它们往往暴露职责不清，应反问：“它代表什么？谁在用它？它自己会做什么？”
- 注意同义词合并：比如“买家”“客户”“会员”，若业务逻辑完全一致，就用一个类，别拆成三个
遵循单一职责原则（SRP）
一个类只做一件事，并且把这件事做好。判断标准是：未来如果需求变化，是否只有一个理由导致这个类被修改？
- 反例：“订单类”既保存订单数据，又生成PDF发票，还调用微信通知——三件事，三个修改点，应拆为 Order、InvoiceGenerator、NotificationService
- 正例：“学生类”只管学生基本信息与学业行为（如选课、查成绩）；成绩计算逻辑属于“成绩服务”，学籍审核属于“教务规则类”
- 接口比类更易体现职责：定义 StudentInfoProvider、StudentEnroller、StudentGrader 三个接口，再由具体类实现，比堆砌大而全的 Student 类更灵活
用组合代替继承，按能力而非血缘建模
避免为了复用而强行拉出父类。继承表达的是“is-a”关系（猫 is-a 动物），但现实中更多是“has-a”或“can-do”关系。
立即学习“Java免费学习笔记（深入）”；
- 不要为“管理员”“普通用户”“游客”建 User ← Admin ← Guest 继承链——权限差异本质是策略配置，可用 Role 对象组合进 User 类
- 需要“能打印”“能导出”“能分享”的能力？定义 Printable、Exportable、Sharable 接口，让需要的类去实现，而不是继承 PrinterUser 或 ExportUser
- 当两个类共用某段逻辑（如日志记录、数据校验），抽成工具类或使用 AOP，别硬塞进继承体系
命名与边界要让人一眼看懂
类名是设计意图的第一传达者。好名字自带约束力，差名字埋下混乱种子。
- 用名词，首字母大写：Order、Payment、InventoryAdjustment（不说 OrderManager 或 DoOrder）
- 避免模糊词：Helper、Util、Handler —— 改成 EmailSender、RetryPolicy、IdempotencyToken
- 包结构反映领域层次：com.example.ecommerce.order、com.example.ecommerce.payment，不混放
- 小技巧：写一句“这个类负责______”，填空卡住，说明职责还没想清
