面向对象设计原则是日常编码中的具体判断，核心在于单一职责、状态受控、策略可插拔和对象创建集中化。类只做一件事，状态变更需语义方法与事件解耦，促销规则通过策略模式动态替换，对象创建交由工厂或建造者封装。
面向对象设计原则不是纸面概念，是在写类、拆模块、改需求时每天要做的判断。关键不是记住名字，而是知道“这里多加一行 if 就埋了坑”“那个字段塞进 Order 类里，下周改支付逻辑就得动三处”。
类只管一件事，别让它既记账又发短信
比如用户注册功能，别把校验、存库、发邮件全塞进一个 UserService 里。一旦数据库换 Oracle 或邮件模板要 A/B 测试，就得改同一个类——改一处，崩三处。
- 拆成 UserValidator（只做参数检查）、UserRepository（只对接数据库）、NotificationService（只管发消息）
- 主流程用组合：new UserService(new UserValidator(), new UserRepository(), new NotificationService())
- 每个类改起来只影响自己那块，别人调用它也只依赖接口，不关心内部怎么实现
状态流转要“有门禁”，不能随便 setStatus
订单从“已支付”跳到“已完成”，中间必须经过“已发货”。如果靠 public void setStatus(OrderStatus s) 暴露出去，测试、运维、新同事都可能误操作。
- 把状态定义为枚举，每个状态明确标注允许流向哪些后续状态
- Order 类只提供 pay()、ship()、complete() 这些语义方法，内部自动校验当前状态是否合法
- 状态变更后发事件（如 OrderShippedEvent），让库存服务、物流服务各自监听处理，主流程不耦合后续动作
变来变去的规则，得插拔，不能硬编码
满 200 减 20、会员打 95 折、新人首单免运费……这些促销逻辑一个月一变。如果全写在 Order.calculateTotal() 里，每次上线都要改核心类，风险高、回归难。
- 定义 PromotionStrategy 接口，含 apply(Order order) 方法
- 每种策略单独一个类：FullReductionStrategy、MemberDiscountStrategy、NewUserFreeShippingStrategy
- 下单时根据用户身份、商品类型等条件，用简单工厂选一个策略实例，调统一方法即可
- 新增活动？加个类，配个开关，不用碰老代码
对象创建别散落在各处，集中交给工厂或构建器
一个订单对象初始化，可能要根据地区决定税费计算方式、根据用户等级决定是否启用极速退款、根据设备类型调整收货地址格式——十几个 if 堆在 service 里，可读性差，还容易漏判。
- 用工厂类封装所有创建逻辑，对外只暴露 createOrder(request) 一个方法
- 工厂内部可用查表、策略链或配置中心拉取规则，但调用方完全无感
- 复杂对象考虑用建造者模式：new OrderBuilder().withUser(user).withItems(items).withPromotion(p).build()
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
