高内聚低耦合是面向对象思想落地的自然结果，设计模式仅标准化职责划分与依赖解耦；策略模式应对多变逻辑，接口隔离、构造注入、组合优于继承、职责命名具体、AOP剥离横切关注点、校验与DTO各司其职。
高内聚低耦合不是设计模式的副产品，而是面向对象思想落地时自然达成的状态。设计模式只是把实践中反复验证过的职责划分、依赖解耦、行为封装方式标准化了——用对了，代码就更内聚、更松耦合；用错了，反而加重混乱。
用策略模式把“多变逻辑”从主干中摘出来
当一个方法里频繁出现 if-else 判断渠道、支付方式、导出格式时，说明它正在承担多个变化原因。这不是业务复杂，是职责没划清。
- 定义接口如 PaymentProcessor，只声明 process(Order order)
- 为每种支付方式写独立实现：AlipayProcessor、WechatProcessor、CreditCardProcessor
- OrderService 只持有 PaymentProcessor 接口，运行时由 Spring 注入或工厂返回
- 新增 PayPal 支付？加个新类 + 配置，原 OrderService 一行不改
用工厂+接口组合替代 new 和静态调用
硬编码 new UserRepositoryImpl() 或调用 StringUtils.isBlank()，等于把实现细节和工具细节焊死在业务逻辑里，一动全抖。
- 所有外部协作对象（数据库、HTTP 客户端、缓存）必须通过构造函数注入，类型为接口
- Controller 层只依赖 UserService，UserService 只依赖 UserRepository 和 NotificationSender
- 工具类如 DateHelper、JsonParser 要抽成带业务语义的组件，比如 OrderDeadlineCalculator、ApiResponseBuilder
- 测试时能直接传 new MockUserRepository() 运行通过，就是依赖设计合格的标志
用组合代替继承，让类只对一种变化负责
继承容易把父类的字段、生命周期、甚至 bug 一起继承过来。而组合让你明确知道“我需要什么能力”，而不是“我是什么类型”。
立即学习“Java免费学习笔记（深入）”；
- User 类不继承 Person，而是持有一个 NameFormatter 和一个 PhoneValidator
- 订单状态流转不靠 if (status == PAID) { ... }，而是封装在 Order 类内部：order.transitionTo(PAID)
- 避免 XxxManager、XxxHelper 这类命名，改用 OrderCancellationPolicy、EmailTemplateRenderer 等直指职责的名字
用 AOP 剥离横切逻辑，还原业务主干
事务、日志、参数校验、幂等控制这些通用逻辑如果混在 service 方法里，会让核心流程被技术细节淹没，也导致一个方法同时对“业务规则变更”和“日志格式调整”负责。
- @Transactional 放在 repository 层或用 AOP 统一拦截，别写在 service 方法上
- 用 @Valid + 自定义注解做校验，而不是在方法开头堆 if (user == null || user.getEmail() == null)
- 审计日志由 AuditLogger 类统一处理，业务方法里只留一句 logger.info("Order {} paid", order.getId())
- DTO 仅用于跨层传输，不参与任何判断、格式化或加密——这些都该属于领域对象或专用组件
