面向对象设计原则需转化为具体编码习惯：类应小而专，按单一职责拆分；状态变更须带校验与语义约束；多变逻辑用接口隔离；封装重在行为边界控制而非仅字段隐藏。
面向对象设计原则不是写在文档里的口号，而是每天写类、改方法、加功能时的具体选择。落地的关键，在于把抽象原则转化成可执行的编码习惯和结构约束。
类要小而专，别堆逻辑
一个类只负责一件事，变化原因只有一个。比如订单系统里，别让 Order 类既管状态、又算价格、还发短信。拆成 Order（核心字段+状态流转）、PricingService（价格计算）、NotificationService（通知发送）更稳妥。
- 用户注册逻辑单独抽成 RegisterService，不混在 UserService 的数据库操作或邮件发送里
- 商品详情页需要展示库存、价格、促销标签？用组合：Product + StockInfo + PriceCalculator + PromotionBadge，而不是往 Product 里塞一堆 getter 和 if-else
- 检查类是否“胖”：如果它有超过两个 public 方法涉及不同业务域（比如既有 saveToDB() 又有 sendSms()），大概率该拆了
状态变更必须带校验和语义
订单不能从“已完成”退回“待支付”，用户不能从“禁用”直接切到“超级管理员”。这些规则不能靠开发自觉，得靠代码守住。
- 用枚举定义状态，并在 OrderStatus 中声明合法转移路径（如 CREATED → PAID 允许，CREATED → COMPLETED 不允许）
- 提供 pay()、cancel()、ship() 这类动词方法，内部先 checkState() 再执行，失败就抛 IllegalOrderStateException
- 状态变更是事件源：调用 ship() 后发布 OrderShippedEvent，由监听器处理减库存、推物流信息——主流程不耦合后续动作
多变逻辑用接口隔离，别硬编码
优惠策略、支付方式、审核规则……这些业务常改的部分，必须做到“加新不改旧”。
- 定义 PromotionStrategy 接口，含 calculateDiscount(Order order) 方法；满减、券、会员折上折各自实现，互不影响
- 主流程中通过策略工厂（或 Spring @Qualifier）按条件选实例，然后统一调 strategy.apply()，不再出现 if (type == "COUPON") { ... } else if ...
- 同理，支付用 PaymentStrategy，审核用 ReviewPolicy —— 新增一种支付方式，只加一个类，不碰原有任何代码
封装不只是 private + getter/setter
真正的封装是控制行为边界，不是只锁字段。
- User 构造时校验邮箱格式，不合法直接抛异常，避免后续空指针或脏数据流入
- Order.setTotalPrice() 做正数校验，而不是让调用方自己判断“if (price > 0) order.setTotalPrice(price)”
- 集合类属性不用 public List
- getItems()，改用 unmodifiableList(getItems()) 或提供 addItem/removeItem 方法，防止外部直接 clear() 或 add(null)
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
