类图设计应聚焦“谁在做什么、状态怎么变、边界在哪里”：从角色职责定义类，用业务语义命名，封装状态变更逻辑，通过方法嵌入校验规则，引用关系反映真实协作，类图需体现枚举、bigdecimal等类型安全设计。
把现实业务场景转化成类图，关键不是照搬现实，而是抓住“谁在做什么、状态怎么变、边界在哪里”这三点来设计。
先从角色和职责出发定义类
别一上来就写 User 或 Order。先问清楚：这个事物在系统里承担什么角色？它有哪些稳定特征和必须响应的动作？
- 比如“订单”，核心不是一堆字段，而是有明确生命周期的业务实体：它有编号、创建时间、金额、状态（待支付/已发货/已完成），能执行“提交”“取消”“发货”“计算总价”等动作
- 再如“库存项”，重点不是“有多少件”，而是“能否扣减”“是否预警”“归属哪个仓库”——这些决定了你要暴露哪些方法，而不是只提供 getQuantity() 和 setQuantity()
- 类名要体现业务语义，避免泛泛的 Info、Data，优先用领域术语，如 PaymentGateway、RefundPolicy
用封装约束状态变更逻辑
属性私有化只是起点，真正重要的是把业务规则嵌入行为中。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 订单状态不能被外部直接设为 "shipped"，而应通过 ship() 方法触发：内部检查是否已支付、是否有库存、是否超时，全部通过才更新状态并记录日志
- 用户余额不能直接赋值，而要提供 addBalance(BigDecimal) 或 deductBalance(BigDecimal)，并在方法内校验是否为负、是否超过信用额度
- 构造函数强制初始化关键字段：订单号、用户ID、创建时间必须在创建时确定，避免出现“半成品”对象
让类之间的关系反映真实协作
多个类之间的引用关系，要体现真实的业务依赖，而不是技术便利或数据库外键映射。
- 一个订单持有对用户的引用（private User buyer），但不持有对物流公司的完整实例——只需知道运单号和当前物流状态，避免过度耦合
- 部门与员工是一对多关系，员工对象里存 Department dept 引用，部门对象里维护 List
staff；双向关联需谨慎管理生命周期，防止内存泄漏或状态不一致 - 理解引用本质：两个变量指向同一订单对象时，调用 orderA.cancel() 后，orderB.getStatus() 自然返回新状态——这不是 bug，是协作的基础
映射到类图时保持语义清晰
类图不是代码的截图，而是业务逻辑的可视化表达。
- 状态字段在 Java 中用枚举类型（如 OrderStatus），而非 String 或 int，保证类型安全和可读性
- 金额字段用 BigDecimal，时间字段用 Instant 或带时区的 ZonedDateTime，避免浮点误差或时区歧义
- 类图中每个类用标准三栏矩形表示：类名（加粗）、属性（含可见性符号 - / + / # 和类型）、方法（含参数和返回类型）；接口标注 >，继承用空心三角箭头，实现用虚线+空心三角
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
