接口定义能力契约，抽象类封装通用流程，具体子类实现差异化逻辑：PaymentProcessor声明行为，AbstractChannelProcessor提供模板骨架并强制子类实现buildRequest()和parseResponse()，WechatProcessor等仅专注渠道特有逻辑。
接口与抽象类组合使用，核心是“契约先行、骨架居中、实现落地”——接口定义能力边界，抽象类封装通用流程，具体子类专注差异化逻辑。这种分层设计让框架既松耦合又易扩展。
用接口声明能力契约，隔离变化点
先定义清晰的行为规范，不涉及任何实现细节。比如支付框架中：
-
PaymentProcessor 接口只声明
process()、refund()、queryOrder()三个方法 - 所有渠道（微信、支付宝、云闪付）都必须实现它，但彼此完全无关
- 业务层只依赖该接口类型，运行时才注入具体实现，替换渠道无需改业务代码
用抽象类提供模板骨架，复用稳定逻辑
当多个实现共享大量流程或状态时，抽象类作为中间层介入：
-
AbstractChannelProcessor 继承自
PaymentProcessor，实现公共逻辑：统一验签、日志埋点、异常转译、幂等校验 - 定义
buildRequest()和parseResponse()为 abstract 方法，交由子类定制 - 构造器中加载渠道私钥、配置超时参数等初始化动作，接口无法支持
组合落地：接口 + 抽象类 + 具体实现
典型三层结构如下：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
-
接口层：
PaymentProcessor—— 所有调用方的统一入口 -
抽象层：
AbstractChannelProcessor—— 提供默认流程+强制子类补全关键步骤 -
实现层：
WechatProcessor、AlipayProcessor—— 只写真正差异化的请求组装和响应解析
这样新增一个渠道，只需继承抽象类、实现两个抽象方法，其余能力自动继承，框架主干零修改。
注意 default 方法的使用边界
JDK 8+ 允许接口加 default 方法，但仅适用于：
- 无状态、纯函数式逻辑（如
CollectionUtils.isEmpty()类型的空值判断） - 简单转换（如
toMap()、filterNotNull()） - 绝不放入需访问实例字段、依赖构造参数、含复杂初始化或事务控制的逻辑——这类必须留在抽象类中
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
