行为接口重构的核心是厘清职责边界、实现变化隔离，而非简单添加interface；需识别超载场景、命名体现能力、实现类单一专注、构造器注入依赖、枚举内聚策略，确保每次修改影响范围可控。
用行为接口重构业务系统，核心不是加一堆接口，而是把“谁该做什么”想清楚、切干净。重点不在语法层面的 interface 关键字，而在职责是否真正分离、变化是否彼此隔离。
先识别该抽成行为接口的逻辑点
以下情况基本说明当前类已超载，适合拆出行为接口：
- 方法里出现 if (type == "sms") / else if (type == "email") 或 switch 处理多种执行路径
- 一个类同时包含「生成订单」「发送通知」「更新库存」「写日志」等跨领域动作
- 单元测试需要 mock 超过 3 个协作对象，或 mock 后仍难覆盖边界场景
- 新增一种支付方式（如 Apple Pay）或通知渠道（如 DingTalk），必须改已有类的源码
定义行为接口要聚焦“能做什么”，而非“是什么”
接口名体现能力，方法签名体现契约，不暴露实现细节：
- ✅ NotificationSender：void send(NotifyMessage message)
- ✅ PaymentProcessor：PaymentResult process(PaymentRequest request)
- ✅ InventoryChecker：boolean hasEnough(String sku, int quantity)
- ❌ NotificationService（太泛）、PayUtil（工具味重）、InventoryCheckHelper（命名暴露实现意图）
实现类严格对口单一场景，不越界
每个实现类只解决一类具体问题，且不持有无关依赖：
立即学习“Java免费学习笔记（深入）”；
- EmailSender 只管构建 MimeMessage + 调 SMTPClient，不查用户表、不写日志
- RedisInventoryChecker 只连 Redis 执行 DECRBY，不碰数据库、不处理异常降级逻辑
- 若需失败重试，由上层编排（如 NotificationOrchestrator），而非塞进 EmailSender 内部
- 避免在实现类中 new 具体工具类（如 new SimpleDateFormat()），应注入 DateFormatter 接口
业务主流程通过构造器注入行为，不感知实现
让核心类轻量、可测、可替：
- OrderService 构造函数只接收 NotificationSender、PaymentProcessor、InventoryChecker 等接口
- 不 import 任何 xxx.impl 包，不 new 任何具体实现类
- 测试时直接传 new MockNotificationSender() 或 InMemoryPaymentProcessor()
- Spring 中优先用 @Autowired 构造器注入，而非字段注入——确保依赖不可为空、初始化即完整
配合枚举或策略工厂做动态分发（按需）
当行为类型有限且稳定，可用枚举内聚策略：
- 定义 enum NotificationChannel { EMAIL, SMS, WECHAT }
- 在枚举中声明 abstract NotificationSender sender()，各枚举项实现对应 sender 实例
- 调用方用 channel.sender().send(msg)，无需 if-else，也不引入额外工厂类
- 新增渠道只需加枚举项 + 实现 sender()，零修改原有调用链
不复杂但容易忽略：行为接口的价值，不在它多“高级”，而在于每次新增或修改时，你改的代码是不是就那一个文件、影响范围是不是一眼可见。做到这点，高内聚低耦合就落地了。
