抽象类与接口是分工协作的搭档：接口定义组件能力契约（如datasink声明write/close），支持多实现与组合；抽象类封装通用骨架（如abstractdatasink提供重试、资源管理），通过模板方法+钩子确保流程一致，子类仅需实现核心抽象方法。
抽象类与接口在组件设计中不是二选一的关系，而是分工协作的搭档：接口定义“这个组件能提供什么能力”，抽象类负责“这类组件共有的运行方式”。这种配合让组件既可插拔、又易复用。
接口定义组件能力契约
组件对外暴露的行为必须清晰、稳定、不绑定实现细节。接口正适合承担这一角色：
- 一个组件接口（如 DataSink）只声明 write(data)、close() 等核心方法，不关心数据怎么落盘、连的是文件还是数据库；
- 多个不相关的组件（FileSink、KafkaSink、InMemorySink）可同时实现该接口，调用方只需依赖接口，随时替换实现；
- 接口支持组合——一个组件可实现 DataSink + HealthCheckable + Configurable 多个接口，能力正交、职责分明。
抽象类封装组件通用骨架
当多个组件共享初始化、资源管理、重试逻辑、指标上报等重复代码时，抽象类是自然的归宿：
- AbstractDataSink 实现 DataSink 接口，并内置：统一连接池管理、写入前校验、失败自动重试模板、close() 中的资源释放保障逻辑；
- 子类（如 JdbcSink）只需覆盖 doWrite() 和 doClose() 这两个抽象方法，其余全部复用；
- 抽象类还可持有状态字段（如 retryCount、metricsRegistry），这是接口无法做到的。
模板方法+钩子函数驱动流程一致性
组件的生命周期或处理流程往往有固定顺序，但关键步骤因实现而异。抽象类结合接口可优雅落地：
- 在 AbstractDataSink 中定义 public final void write(Data data) 模板方法，强制执行：preValidate → doWrite → postAck → updateMetrics；
- 其中 preValidate() 和 postAck() 可提供默认空实现（即“钩子”），子类按需重写；
- doWrite() 声明为 abstract，子类必须实现——确保核心行为不被跳过，又不限制技术选型。
面向接口编程，依赖抽象类扩展
在依赖注入或插件化场景中，两者的配合体现得最明显：
- 配置中心根据类型名加载组件实例，先通过反射确认其是否继承自 AbstractDataSink（保证基础合规性），再将其转型为 DataSink 接口供业务使用；
- Spring 或类似容器中，@Bean 方法返回接口类型，但实际注册的是抽象类的子类实例，上层完全无感；
- 新组件开发只需继承抽象类、实现抽象方法、打上对应接口标记，即可无缝接入现有调度、监控、配置体系。
