java接口多实现时方法职责混淆源于设计问题，需用领域前缀明确行为归属、接口名体现能力契约、避免default方法泛滥，并遵循“动词+业务对象+修饰”命名结构。
Java 中接口多实现时，方法职责混淆往往不是语法问题，而是设计信号——名字相同但语义不同，说明接口边界没理清。规范命名的核心目标是让方法名自带上下文，一眼区分行为归属和业务意图。
用领域前缀明确行为归属
避免泛化动词如 load()、validate()、log() 单独出现。加上限定词，把“谁在什么场景下做什么”写进名字里：
- cacheLoad() vs dbLoad() —— 区分数据来源
- orderValidate() vs userValidate() —— 绑定校验对象
- auditLog() vs debugLog() —— 表明日志用途
前缀不必冗长，但需具备业务辨识度。比如 “http”、“retry”、“metric”、“fallback” 都是高频且无歧义的领域标识。
接口名本身要承载职责信息
接口不是功能集合，而是能力契约。命名应体现“它代表什么”，而不是“它能干什么”：
- 用 OrderPaymentProcessor 替代 Payment（后者太宽泛，易与其他 Payment 接口冲突）
- 用 IdempotentMessageConsumer 替代 MessageHandler（强调幂等这一关键约束）
- 用 AsyncRetryableTask 替代 Task（把可重试、异步两个关键特征前置）
这样，当类实现多个接口时，方法签名即使同名（如 execute()），也能通过接口名快速判断该方法在当前上下文中的具体含义。
抽象方法不加 default，把通用逻辑外移
default 方法一旦出现在多个接口中，就天然埋下冲突隐患。真正通用的行为，不该塞进接口契约，而应：
- 抽成工具类：如 RetryUtils.executeWithBackoff()、JsonSerde.toJson()
- 封装为模板方法：在抽象基类中定义流程骨架，子类只实现钩子方法
- 交由 Spring 等框架管理：用 @Retryable、@Transactional 等声明式能力替代接口内嵌逻辑
接口只保留不可替代的、与领域强相关的抽象方法，命名自然更聚焦、更难重叠。
方法命名遵循“动词 + 业务对象 + 可选修饰”结构
参考 Java 标准库和主流框架的惯用法，保持动词开头、对象明确、修饰精准：
- ✅ findActiveUserById() —— 动词（find）+ 状态（Active）+ 对象（User）+ 方式（ById）
- ✅ submitOrderForProcessing() —— 强调动作目的（ForProcessing），区别于单纯 submitOrder()
- ❌ doWork()、handle()、process() —— 模糊，无法体现职责差异
当两个接口都有 process() 时，你无法判断哪个负责风控、哪个负责投递；但换成 processRiskDecision() 和 processDeliveryEvent()，职责一目了然。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
